Asynchronous JavaScript and XML or AJAX is hot, so hot that it has become a buzzword. Will AJAX save the day for mobility applications? Will it really displace smart clients? Will it solve the problem of market fragmentation? Porting woes? Application distribution without walls? Will AJAX replace J2ME and XHTML as I recently have read? Is AJAX Mobility 2.0?

After reading recent posts about how AJAX is the medicine when it comes to mobility app development, I have to say: STOP! For the sake of new developers entering this space let's not confuse things. No, AJAX will NOT save mobility from fragmentation, porting issues, and so on.

There are fundamental differences between browser-based (or thin clients) and smart/rich clients — and this comes to no surprise to experienced developers. There also are reasons and requirements why you would create a browser-based vs. a smart client application. In short, the argument that one approach to mobile applications will replace the other is completely flawed.

If the application you are developing can be expressed and meets its requirements using the thin client pattern, then go for it — as with your desktop browser app, the app logic mainly resides on the server, and these clients need to connect to the server before doing anything meaningful, and these type of clients don't require advanced handset functionality such as retrieving positioning information, integrated messaging, multimedia or persistence. Yes, choose this application approach if you can, as you don't have to be concerned with application re-distribution issues, and it should work OK on most of the browsers, assuming you follow proper XHTML programming styles.

So when would you create a smart client? Well, if you are writing an advanced application, if your application requires advanced functionality on the handset such as the ones mentioned above (access to positioning lat/lon, advanced messaging, advanced graphics, data sessions/network connectivity, multimedia, etc.), you need a smart client. Examples are Google Local for Mobile, Yahoo! Go Mobile, and many others…

Anyhow, let me go over some of the arguments I've read:

  • It solves the problem of market fragmentation. It solve porting woes.

    • Answer is No, and no. If you have written mobile browser applications you know there are portability issues: lack of consistent support for CSS, table support, same with images and fonts, and more recently AJAX (only Opera mobile browser supports this today), and so on. So fragmentation already exist in mobile browser-based apps. To work around this, you must adhere to programming styles, as the ones I mentioned above, and avoid AJAX. I have written about this before, and you can find the article Writing Consistent Mobile Browser Content on Sprint Phones on the Sprint developer website (requires registration).

    From the API perspective (here I am talking about Java ME apps), fragmentation do exist, but this is being addressed with the Mobile Services Architecture (for CLDC) specification (I am personally putting a lot of faith on this spec), where soon (starting on 2006), all the advanced APIs, from location to messaging to advanced graphics, will all be present on all MSA-compliant handsets.

    Even if the Opera Mini, Mobile and Platform were to provide great support for CSS and tables and images and fonts, etc, and access to native services and advanced functionality on the handset, it still would be only one browser/framework vendor with its own API, still resulting in fragmentation. On the positive side, we should expect support for AJAX by other mobile browsers, as well as better support for CSS — but don't know by when.

  • Will it solve Application distribution without walls?

    • Answer is No. The problem is not redistribution of application — regardless of the application being a thin or smart client, the main issue is about access to the network, to the services on the web.

  • AJAX replace J2ME and XHTML.

    • Answer is No, it won't replace Java ME, or native applications, or XHTML. As I previously mentioned, there are times when you only require a thin application, and there are times when the application requires advanced functionality thus it needs to be a smart client. A good example of this is an application that was announced today, that could have been a written as a thin client for most of its functionality, but it wasn't because part of its requirements were access access to advanced functionality on the handset is Yahoo! Go Mobile.

I can go on an on, but I think the rationale for one vs. the other should be clear
— both application patterns are complementary.

That said… instead of AJAX replacing smart clients, or vice-versa, convergence between thin and smart clients is what I've foreseen, and is something I've researched and worked on in the past — I've called this lightweight clients, where smart-clients leverage the browser (i.e. an embedded browser) to provide the best of both worlds — dynamic XHTML-based UI, smart caching with synchronization, offline behavior, persistence, networking, and now JavaScript and XMLHttpRequest, and because lightweight clients run within the Java ME runtime, they also have access to the runtime and all the advanced functionalities and APIs on the handset. Browser and smart client convergence has great potential. Note that Opera has the right idea, with the browser and the services, but it should extend the browser beyond AJAX, and allow for a true converged smart-browser-client.

Also see Tom Hume's post on this topic.

Update: See Thomas Landspurg's viewpoint on this topic.

Update: See
Hinkmond Wong's viewpoint on this topic.

Update: See and add your vote —
Poll: Mobile AJAX vs. Java ME

[Via
John Kern's blog]

Related blog entries:

* The Web 2.0 from a Practical Perspective

* A Response to “Mobile Web 2.0: AJAX for mobile devices as the preferred platform for mobile app development”

ceo