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. Fundamentally, AJAX (Asynchronous JavaScript + XML) enables back-channel communication in Web applications so that only small portions of Web pages need to be updated in response to user activity. Compared with traditional Web applications that follow the familiar pattern of waiting for a whole page to load, deciding what to do, clicking and waiting again, AJAX applications offer a better user experience. Plus, if done right, an AJAX-style application can reduce both bandwidth and server requirements. 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?

AJAX requires significant mastery of JavaScript, which, unfortunately, is one of the most maligned, misunderstood programming languages in widespread use. Many developers see it as a toy scripting language with a C-like syntax, relegated for use in building simple Web-page embellishments or setting up Web-form validation. However, we'd argue that JavaScript is actually a powerful prototype-based, object-oriented scripting language, closer to functional programming languages widely used in academia, such as SELF and Scheme, than to its cousin-in-name Java. Admittedly, JavaScript's negative reputation is not completely unfounded. Incompatibilities in the JavaScript object models supported by various browsers can make coding quite a chore. The language also lacks widespread tool support, making extensive system development and debugging onerous. The fact that companies such as Microsoft and Google have built mission-critical Web applications that rely heavily on client-side JavaScript is no small feat.

Pitfalls of developing an AJAX app

While it may seem relatively easy for intermediate JavaScript programmers to code an AJAX-style communication, quite a few potential problems can arise in the process, ranging from cross-browser issues to error conditions. Furthermore, programmers likely will need a new set of rich widgets to implement a desktoplike interface. This leads to some confusion as rich widgets thought of as DHTML (basically, just JavaScript with Cascading Style Sheets) are now reborn as AJAXifed widgets. 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. The most troubling aspect of AJAX applications facing Web developers is that they are often built with the assumption that they will run in a best-of-all-possible-worlds environment. In this utopia, users never turn off their JavaScript midvisit, hackers don't try to corrupt payloads, network and server errors rarely occur, bandwidth is plentiful, CPUs are always fast and available, and latency is LAN-like, at worst. 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. Network outages and hiccups can slow or kill poorly coded AJAX applications with little warning. You can even hang some AJAX applications without a warning message simply by disabling JavaScript. Rarely did we see automatic talkback code to alert site owners to JavaScript errors, which would be a natural fit for the technology. Checking for client CPU responsiveness that may slow an animated user interface is mere wishful thinking today.

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. If only an ID is needed, a text string returns with the ID. If more complex data must be returned, developers use a format called JavaScript Object Notation, which tends to be much terser than XML. 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. A lax security posture is most evident in that many AJAX applications are delivered with unobfuscated and unoptimized JavaScript. This condition allows easy access to intellectual property by unscrupulous developers, sets no barriers for code inspection by potential intruders and uses more bandwidth. Tools exist to help this situation, but more work needs to be done to secure code and communication to move to a more client-centric development style. 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.

Originally published on Network World, Published: July 17, 2006.