One of the next buzzword these days is “Mobile Ajax“, as THE technology that will save mobile applications. This was especially true with the recent announce of “SoonR”, the first mobile enabled Ajax application. Looks good, but unfortunately, I have no Ajax enabled browser out of the thousands of handsets we have here at MobileScope….
But this generates some buzz, and as usual, some hype. So, in a “back to reality” attempt, I’ve tried to discuss a few myth of “mobile Ajax” here:
- Mobile 2.0=Mobile Web2.0 (and Mobile Web2.0 = Ajax on mobile). Wrong, as this imply a choice of technologies. The good thing (or is it a bad thing?) with mobile, is that there is a huge choice of technologies. If mobile is connected, does not mean that it is connected only through browser.
- Ajax is the only technology to create mobile mashups: (this is the same wrong statement than in the web): No, basically ALL technologies can be used to create mashup, to access to existing Web services:
- J2ME (and not need to use “JSR172″ to do this)
- FlashLite can do it to
- Native OS of course….
- Even Wap/Html/Xhtml can be used to create mashups…
- A few example of personal mobile mashups (done in “plain J2ME”)
- Ajax applications will run the same on mobiles than on PC, and this will save us some porting costs. Wrong! Seems that the Write Once Run Anywhere myth is back!! It was actually already not achievable through technology designed for this, so I did not see how Ajax app (which is basically designed for one or two platform) will be able to address suddenly thousands of different platforms….. And all the existing so called mobile Ajax applications are ALREADY specific for mobile. The SoonR mobile version is not the same one than SoonR on PC….
- Ajax applications are a way to by pass operators….There is
absolutely NO link between operators and this. Java, Flash, Symbian
applications can be acceded directly by end user as well as Ajax
applications (and with a bigger installed base). In fact, there is a
link: as an Ajax is an online application, it’s easiest for them to
block certain site if they want too….And no way to install it outside
the browser! The biggest issue is not the access, is the billing…Or
the business model. How to make end user pay for services in an easy
I like Ajax as one of the technology that I could use to create a better experience, but as discussed in one of my previous post, I think that the complexity needed both in the browser and the application is unnecessary on mobile device, and we should take the mobile opportunity to solve some of the technical issue raised by Ajax on the web. There is also an interesting article from Dioan Hincliffe raising a few of the Ajax issues: Seven things that every software project needs to know about ajax.
A few of his remarks:
- Ajax applications are complex applications (even if they are doing simple things). This leads to this comment: “Good Ajax programmers are hard to find”
- The browser model (of Ajax) haves some limitation: no way to access to some local resources of the handset…
- The browser was never made for Ajax. In other way, ajax developer used the installed base of modern browser to create something unique.
Now, back to mobile….Should we try to duplicate current ajax complexity to mobile, with one model, or can we try to solve some of the issues of Ajax?
I am a strong believer of the last option. There are already three technologies that will play significant role in the future: J2me, FlashLite, and Ajax. Only one is really deployed now and it’s J2me. FlashLite is on the way and Ajax far from being a reality yet. But these three are complementary, and could work together in a perfect way, in a different and better model than on the web.