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 the inherent dangers of the same. 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.
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 real 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 that kind of thing. While the Document Object Model allows for some dynamics, the current HTML elements standard just don't provide enough flexibility. 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.
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. IFrames offer a good alternative solution for composing independent components.