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.
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.
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.