An axe to grind with Ajax

What could possibly get a bunch of Java geeks so excited? We always have pizza at the meetings, so that wasn't it...To my bewilderment, it was a technology whose acronym "AJAX" stands for "Asynchronous JavaScript and XML." (It wasn't even Java.)

Since that evening, I've spent quite some time researching the AJAX phenomenon, and I've come to a conclusion: I don't get it. AJAX allows a client that is running in a Web browser to communicate asynchronously with a server and to update the browser page dynamically. OK, that's nice; I have always hated browser-based applications that force you to click your way through endless forms and exhibit noticeable delays in updating the screen after you've done anything at all.

In fact, with a few exceptions, I have hated just about every browser-based application that I've ever used. For me, the browser just isn't a good application container. Yes, it is workable, but you constantly find yourself fighting the browser's weaknesses rather than leveraging the browser's strengths. Back button and history issues, security issues, session management issues and HTML/JavaScript incompatibilities all come to mind.

AJAX happens to solve one of the problems--a problem that wouldn't exist if the browser weren't such a lousy application container.

AJAX is sexy, but it is hardly revolutionary.

It seems like most legitimate use cases of AJAX make a browser-based application behave more like a rich or smart-client application. What's wrong with rich or smart-client platforms for developing rich or smart-client applications? What's wrong with serving a rich, interactive GUI (graphical user interface) as a Java applet or even as a Java Web Start application, for example?

Over many years, I have seen some beautiful examples of such applications that communicate asynchronously with a server and leverage the complete set of powerful, built-in GUI components.

AJAX is new. AJAX is sexy, but it is hardly revolutionary. I am neither a GUI nor a browser specialist, but I have been able to develop some really nice, portable application interfaces as Java applets for years now. They were at least as portable as AJAX applications are, and they did some things with trivial effort that you would have to work really, really hard for in AJAX.

I certainly admire what the Google engineers did with Google Maps, and I agree with 99.9 percent of people that a rich e-mail client GUI is much nicer than the silly old-fashioned Web mail client interfaces were. I thought to myself: "Man, how did they do that in a browser without applets or embedded objects?"

I admire these solutions the same way I would admire a really smart library that gives a COBOL application similar list-processing capabilities to a Lisp one. There's nothing wrong with the engineers who created the solution. It's the people who wrote the requirements that baffle me. Why do we keep working around browser limitations when someone could be making the browser a better application container?

Before jumping on the AJAX bandwagon, be sure to ask yourself the following questions:

• What problems am I trying to solve?

• Are there other possible solution approaches, and should I re-evaluate them if the last time I looked at them was five years ago?

• What are the security implications of publishing all these XMLHttpRequest endpoints?

Don't misinterpret my discontent as an endorsement of applets over AJAX. Rather, think of it as my reason for asking, "What exactly is it that makes AJAX so wonderful?" Could I have filled a 300-person auditorium with a presentation on "Rich, dynamic Web clients using Java applets?" I'm sure I couldn't have.