If you've used Google Maps, Gmail or Microsoft's Outlook Web Access, you're familiar with the power of AJAX, which gives Web applications the responsiveness users associate with desktop applications.
It's no wonder that AJAX has generated lots of hype. However, before you "AJAXify" your Web applications, you need to be aware of the pitfalls, particularly in the areas of security, reliability and performance.
What's AJAX all about?
Pitfalls of developing an AJAX app
Web developers ultimately need a complete, robust AJAX-focused development stack that will marry client-side and server-side programming in a neat package.
It's likely that Microsoft with its Atlas project and Sun with its various Java 2 Platform Enterprise Edition AJAX examples and components ultimately will win over a large portion of the developer community, particularly when each vendor fully integrates these efforts into its development platforms.
But for now, many early adopters continue to roll their own AJAX libraries, use open source frameworks such as Prototype and the Dojo Toolkit, explore the few more developed commercial platforms from vendors Tibco, JackBe or Backbase, or completely switch gears and adopt a new language such as Ruby with its programmer productivity focused Ruby on Rails Web development framework.
AJAXification issues in the real world
The first question to ask when AJAXifying a Web application is how much asynchronous communication should be employed. Should you simply update a few user interface widgets to speed page use? Or, should the entire application be recoded? Roughly speaking, the more you move to the client side, the faster responsiveness you will get (under ideal conditions). The potential costs are decreased reliability, a more difficult user interface and increased complexity.
Of course, these conditions are unattainable, but it would seem to apply in all cases if you looked closely at most deployed AJAX code. Inspecting live AJAX sites as well as libraries of applications shows little contingency code on the client side to deal with script errors, server time-outs or even outright communication failures.
AJAX adds complexity
AJAX applications often break the "one URL equals one resource" model the Web has long employed. This condition can break the semantics of the browser "back" button from the user's point of view, make bookmarking problematic, ensure that caching is difficult or in some cases impossible, make log files even less useful for user tracking, lock out search bots and make disabling access harder to code for.
In short, the same problems that plague completely Flash-driven sites will also afflict AJAX-powered sites that do not include code to address these concerns. Depending on the application, many of these issues may not matter so much, though it does illustrate that a key AJAX trade-off for faster user responsiveness is added design and code complexity.
AJAX can save bandwidth
Traditional Web applications deliver a tremendous amount of redundant information, particularly if pages are coded in old-fashioned HTML laden with tags. In such sites the amount of structuring and presentation markup required may be nearly as significant as that required to serve up the textual content of the page. However, following an AJAX design pattern, applications need to download page layout and structure items just once, and then update new data as needed, which could significantly reduce the application's bandwidth footprint per user session.
An AJAX application's reduction in request-response size may also free Web server resources. These programs tend to be network bound, because they generally will receive acknowledgments more quickly for smaller payloads and thus can move on to other processing users.
Despite the reduced data payload, many AJAX developers find that XML can be quite bloated as a transport format. Despite the 'X' in AJAX, XML is not required in an AJAX-style application, so many developers issue responses to the browser with as little data as possible.
Another format, YAML, which is promoted by fans of the Ruby on Rails framework, is an even terser alternative. However, before rushing to dump XML as a transport format for something smaller, consider that HTTP compression engines for Web servers such as mod_gzip or httpZip could be used with AJAX just fine.
Not every aspect of an AJAX application necessarily makes a favorable impact on network or server architecture. First, the AJAX style of coding is not overly cache-friendly. AJAX applications typically add cache-control headers so that response data is not cached. In fact, most AJAX applications typically will not work if caching is employed; this is obvious in that they often make multiple calls to the same URL to fetch data.
A further potentially troubling aspect of some AJAX applications is their use of continual polling. Given the desire for interactivity, many AJAX applications are built to poll servers rapidly waiting for system changes. If many users tap such a chatty application, its processes can end up taxing a server farm as much as large downloads would, particularly if the polling is synchronized to a particular time.
An alternative to the polling approach, named Comet, pushes data at users employing long open connections. Unfortunately, Web server software is not built for this kind of communication pattern and may need significant modification if Comet is to be useful.
Security isn't there yet
As for security, AJAX Web applications are as insecure as traditional Web applications. Both are far too trusting of user inputs. SQL injection or other data-manipulation attacks that are just as possible in poorly coded AJAX applications as traditional Web applications, and maybe more so because there is a greater reliance on client activity. This presents new opportunities to poison payloads that get executed client side. Inspecting returned AJAX payloads for correct format and checksums to reduce tampering would seem appropriate, but they are not commonplace yet.
Regardless of implementation complexity, AJAX is unequivocally the future of Web application development. With proper application design and the necessary network architecture in place, Web applications can move from a batch-style approach to near desktoplike interactivity. However, building such applications is not trivial, and when using the Internet the robustness, responsiveness and latency required may be a taller order than some want to believe.
Best practices, tools and frameworks have a way to go before AJAX could be considered the standard approach. Given significant concerns with usability, cost/complexity and security, AJAX should be used appropriately and carefully.
Learn more about this topicTech Ed: Microsoft AJAX framework forges ahead
06/15/06AJAX presents corporate problems, opportunities
05/22/06Sun’s jMaki does mix-and-match AJAX widgets
05/12/06AJAX accelerates Web applications