A cup of AJAX? Nay, just regular Java please.

These days everyone is talking about AJAX. It's supposed to be a cool way of creating Web applications.

The idea is noble: instead of rendering an entire HTML page on each little change on the page, it’s much better to send an asynchronous request that will  get the data for you and refresh only the relevant portion of the screen. Every author writing on AJAX is giving the same (the only? ) examples where this technology is being used: Google maps and email. (BTW, I’m a little sick of these examples). Since I’m not going to be helping Google in improving their maps, I’d like to see some real-world examples implementing  this technology.  Ajax proponents will immediately come with this exciting example of how great it is to refresh some  screen info as the user enters character in a text field. And here's  a sample conversation that might have happened between an imaginary  AJAX supporter and myself.

•  See, I’m just typing the letters of the person’s name, and as I type it prompts me with all potential candidates like in Microsoft Outlook
•  Wow! I like it… as long as you do not have to be a rocket scientist to program this functionality. But wait a minute, do not you think that any entry level Visual Basic/PowerBuilder/Java programmer can do the same thing easily? AJAX applications have to rely on JavaScript, assume the expert knowledge of this not-so-interesting language, different Web browsers may give you different serious issues, may not even always report the problems in communication between you browser and the server, yada-yada-yada..   
• Yeah, but we want this functionality under the Web browser.
• But what about using Java Web Start (JWS) to launch the full-fledged Swing clients? They can easily process events, work the same way under each operational system?
• Yeah, but what if your users  do not have   the JVM?
• But JWS can download it automatically for you.
• Yeah, but what if you are Google, Amazon or EBay and want to have a very thin client.

OK, now we’re talking.  I can agree that big Internet guys can and should invest some serious dough into supporting screen-refresh-on-mouse-move in HTML-based screens. But when it comes to a regular Intranet business application,  when the users/browsers/platforms are known and  when the  cost of the project development matters, I’d stay with a fat client written in Java, or (if you like a fancy GUI) Macromedia’s Flash or Flex.

Many vendors  are happy to offer you a tool to simplify AJAX development, because it’s the right momentum to do so. But development is just the beginning. What about production support? I have a gut feeling that starting an Ajax project is like one way street: it won't be easy to  go back. The users will be more and more demanding, and you'll be spending  most of your time on adding more bells and whistles to the GUI instead of solving  business problems.

Today's  Business Week has published a surprisingly shallow article called "Java? It's so Nineties".  First, a former Sun's employee explains that LAMP is the way to go. After that, they say that the number of published books in Java is 4% off this year while sales of AJAX books is up 68%. Sure, if last year there was just one AJAX  book and now there are three of those, we can even talk about 200% increase. I guess, it's hard to write about programming just by putting together several  search results from Google without having the real-world indusrty experience.

Having said all this, I have to admit taht I also include the talks on AJAX in my Weekend With Experts seminars, because it’s a buzzword and people want to hear about it, but as of today, I’m not going to invest my time in mastering this technology. I’m staying with the good old Java.

links: digg this    del.icio.us    technorati