The state of 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. Did it really transform 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 more like cosmetic surgery than like cosmetics. As such, it comes with inherent dangers. Web 2.0 is a promise and while Ajax is one step, the real web 2.0 is a slow evolutionary process from an information delivery platform to an application delivery platform. 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 the first two of these problems. It eliminates the need for state preservation by encapsulating workflow into a self-contained page. It asynchronously loads small units of content and updates pages dynamically. It provides some notion of event-driven programming to applications. So, what is bad about Ajax?

They say Ajax breaks the back button. They say 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 challenge.

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 sensitive business logic and security relevant information find their way into the front end where they exposed.

The second problem is that Ajax tries to solve an issue which it cannot really solve, namely that of creating a platform for rich UI application development. An application framework is needed for this kind of thing. While the Document Object Model allows for some dynamics, the current HTML standard just doesn’t provide enough flexibility to build rich applications. The work on HTML 5 has begun, but the solution for this problem is not yet in sight. Several alternative 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 for all GUI demands. Also, there is currently no universal browser support for any of these languages.

The third problem is -quite plainly- JavaScript. The JavaScript language is still not powerful enough to support large scale application development. 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 use a large number of libraries. With no dependency management, these 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.

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 is a great solution. If all you need is to display a HTML menu and a few popup windows, you might not need Ajax at all. At this point in time, IFrames offer a good alternative solution for composing independent components.

In a more complex application, where components interact with each other, Ajax is required for reloading and updating component state and/or partial page content. Given the current state of HTML and JavaScript, this is cumbersome at best. So, Ajax may be just the stepping stone for the final solution. What’s needed is quite plainly a framework that takes care of component rendering and better state management. However, a viable application framework for complex front end application programming is not yet in sight.