Second thoughts about AJAX

At the end of 2006, it seems that the Ajax hype is finally cooling off. Perhaps this is a good time for a sober analysis. Ajax has indeed changed the Internet landscape, but has it really transformed the web into web 2.0, or has it been just a cosmetic face-lift? The jury is still out on that. In my opinion, Ajax is not just cosmetics, but cosmetic surgery. As such, it comes with the inherent dangers of the same. What is more, Ajax has failed to deliver on its web 2.0 promise. The real web 2.0 is a slow evolutionary process from an information delivery platform to an application delivery platform. Ajax looks more like an intermediate step to me. Currently we are in web 2.0 alpha stage at best.

However, there is one thing that Ajax has achieved. It has pointed out the shortcomings of the traditional web architecture quite plainly. Number one: state information has to be piggy-backed onto a stateless protocol; number two: the granularity of a page as the smallest unit of information is too crude for a web application; number three: web pages lack a mechanism for creating rich and sophisticated graphical user interfaces. Ajax addresses all three of these problems. It eliminates the need for state preservation by packing workflow into a self-contained page. It asynchronously loads small units of content and updates pages dynamically. It provides UI components and event models to the application by means of JavaScript libraries. So, what is bad about Ajax?

Ajax breaks the back button. Ajax doesn't preserve state. Ajax suffers from network latencies. These are the conventional objections, of which I have to say they are somewhat silly. The broken back button can certainly be fixed; besides it is a small cost for a greatly enhanced UI. State preservation reduces to the same problem. Network latency and response time constitute a much bigger problem for web applications that always reload entire pages, therefore it's hardly and argument against Ajax. So, again, what's bad about Ajax? From the user perspective – nothing really. Ajax does a lot to jazz up web applications and enhance user experience. From a software engineering point of view, however, Ajax is a real nightmare.

Web applications are already a complex mix of technologies, and Ajax adds even more complexity. The principal problem is that the code base is split into client side code and server side code and that they use incompatible languages. This naturally leads to code duplication, increased overhead, reduced maintainability and -in the worst case- Spaghetti code. As long as the client side code deals exclusively with display logic, the separation does not really constitute problem, except that you now have two different kinds of display logic. However, more serious problems loom when controller logic and business logic find its way into the client side code. The temptation for this to happen is just too great. Less experienced programmers and programmers working under pressure of time are especially susceptible. Sooner or later, you might find core logic added to the front end.

The second problem is that Ajax tries to solve an issue which it cannot really solve, namely that of creating a dynamic, rich GUI on a static, penurious platform. Granted, the Document Object Model allows for some dynamics, but the core problem is really given by the inherent limitation of HTML. The standard HTML elements just don't provide enough flexibility and extensibility for a rich GUI. The solution for this problem is not yet in sight, although several approaches exist, such as XForms, and proprietary user interface markup languages, such as XUL and XAML. Some of these solutions provide for Ajax-style refresh mechanisms, others are extensible, but none of them provides a solution to all GUI demands. Perhaps worse, there is currently no universal browser support for any of these languages. Ajax only appears to solve this problem, but in reality, it scripts its way around it.

The third problem is -quite plainly- JavaScript itself was well as browser-specific DOM implementations which make JavaScript/DOM code difficult to create and to work on a great variety of browsers. JavaScript defies or at least complicates standard development procedures, such as debugging, unit testing, integration testing, and automatic code generation. The same test procedures have to be run on different browsers. To cut down on development time, Ajax programmers often use libraries. Unfortunately, libraries tend to bloat web pages, because they provide fixed bundles of functionality, whether needed or not. Ultimately, a JavaScript programmer finds himself with a set of tools and procedures reminiscent to bronze age software standards.

Finally, developers should think hard about when to use Ajax and when not to. According to the KISS principle, throwing in Ajax just for the fun of it, is a bad idea. For example, if you have to display a hierarchical data structure with thousands of nodes, an Ajax tree component that can load nodes and branches dynamically, certainly comes in handy. If all you need is to display a DHTML menu and a few popup windows, you might not need Ajax at all. Using Ajax only for reloading partial page content is likewise a bad idea, in my view. Iframes offer a much cleaner and more maintainable solution to this particular problem. The tendency is of course that web applications become ever more complex and users become ever more demanding. Hence, it is inevitable that web GUIs and traditional GUIs will eventually converge. When this happens, Ajax will probably have served as a stepping stone to the final solution.