In this post: why mobile AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development, Ajit Jaokar explains his view on this topic.
And like Tom Hume in this paper, I disagree with most of his conclusion.
I am a big fan of Ajax (even if I think it’s totally over hyped), and I also personally think that it haves a great potential on mobile, but this kind of statement can only make me react….
His argument is based on the fact Ajax will solve the three following issues:
a) The problem of market fragmentation
b) Porting woes (specific to downloading applications like those built on J2ME)
c) Application distribution without â€˜wallsâ€™
That’s true that market fragmentation is a big issue on mobile. But he did not give any clue why Ajax (so browser based application) will do better than J2me to solve market fragmentation.
The porting woes are also a real problem in mobile world. But this statement is totally false:
To make your  games available worldwide in five languages and on only 50 devices, you would need to create 7,500 different builds. At $2,500 per build, you would require a budget of nearly $19 million simply to handle porting.
First, this is totally wrong. Usually porting costs represent around 100% of the price of the game development (in the Java world, excluding different version like 2D/3D). It’s already incredibly huge, but way below this!
But can Ajax solve this issue? For instance, is Ajax used today to do games? Except very simple casual concept games, not really. And on PC there is usually one binary for a game (and one per platform, PC, Xbox, PS, etc…) . While on Ajax there are already several variant depending of the browser (IE,FireFox, etc…). So if Ajax fragmentation appears already on PC, how can it be better on mobile? Ajax developer will face the same issue of usability, screen size, bugs, etc…on numerous mobile platform. Just like J2ME: it’s easy to write a simple cross platform proof of concept. It’s much harder to have a real application running on all devices.
I predict for “Mobile Ajax” the same pattern than for other mobile technologies:
- first phase: the dream! (write once/run anywhere)
- second phase: the deception (it does not work as expected except on developer device)
- third phase: manual porting/adaptation for every different device
- fourth phase: maturity (a mix of automatic porting with process, devices knowledge and improvements of client )
It happened with Wap, it happens with Java, and it will happen with “MobileAjax”….
- Ajax can not be used to do all the application (and especially not games)
- It will NOT SOLVE the fragmentation issue
Last argument was about application distribution: again, I have no clue why a browser based app would be more widely spread than a downloaded app? The issue is not how to get the application, but how to make it visible: deck placement, advertising, etc… Again, Ajax,J2ME, Brew, etc…issue remains the same…
And do not forget one things also very specific to mobile: even if it’s a very connected device, it’s not always connected to the internet. The difference between offline/online content (through preloaded things, download, caching mechanism, etc…) is much more important than on a desktop. That’s also partof the intelligence of the application, specific to mobile.
Another interesting comment, is why Google (the one who put Ajax in the spotlight) and Yahoo did not choose Ajax to do their mobile client? (if you’ve ever tried to run Google Map on OperaMini, you know why! ).
And may be there are more creative way to evolve. I really think that Ajax and J2ME offers a perfect mix of technology to create much more creative application, Ajax for the purely “web based” part, J2ME for the more “client based” approach… Again, the MobileWidget experiment is another example of attempt to use this mix between J2ME, XML/HTTP request, and a scripting language in a different way…