Ajax: A New Approach to Web Applications

Ideas Sections:
Blog
Reports
Latest essay
Newsletter
Essay archives
Reading list
Recent Essays
Project Management for Creative Teams: Art and Science
April 2, 2008
Kate Discusses the Role of Design in Business with Nathan Shedroff
March 18, 2008
Secil Watson Tells Jesse James Garrett About Experience Design at Wells Fargo
March 12, 2008
Stephen Anderson Tells Todd About Implementing Visionary Ideas
February 28, 2008
Indi Young Tells Kate About Mental Models & Her New Book
February 6, 2008
Essay Archives »
byJesse James Garrett
February 18, 2005
Ifanything about current interaction design can be called “glamorous,”it’s creating Web applications. After all, when was the last time youheard someone rave about the interaction design of a product thatwasn’t on the Web? (Okay, besides the iPod.) All the cool, innovativenew projects are online.
Despite this, Web interaction designers can’t help but feel a littleenvious of our colleagues who create desktop software. Desktopapplications have a richness and responsiveness that has seemed out ofreach on the Web. The same simplicity that enabled the Web’s rapidproliferation also creates a gap between the experiences we can provideand the experiences users can get from a desktop application.
That gap is closing. Take a look atGoogle Suggest. Watch the way the suggested terms update as you type, almost instantly. Now look atGoogle Maps.Zoom in. Use your cursor to grab the map and scroll around a bit.Again, everything happens almost instantly, with no waiting for pagesto reload.
Google Suggest and Google Maps are two examples of a new approach toweb applications that we at Adaptive Path have been calling Ajax. Thename is shorthand for Asynchronous JavaScript + XML, and it representsa fundamental shift in what’s possible on the Web.
Defining Ajax
Ajax isn’t a technology. It’s really several technologies, eachflourishing in its own right, coming together in powerful new ways.Ajax incorporates:
standards-based presentation using XHTML and CSS;
dynamic display and interaction using theDocument Object Model;
data interchange and manipulation usingXML and XSLT;
asynchronous data retrieval usingXMLHttpRequest;
andJavaScript binding everything together.
The classic web application model works like this: Most user actionsin the interface trigger an HTTP request back to a web server. Theserver does some processing — retrieving data, crunching numbers,talking to various legacy systems — and then returns an HTML page tothe client. It’s a model adapted from the Web’s original use as ahypertext medium, but as fans ofThe Elements of User Experience know, what makes the Web good for hypertext doesn’t necessarily make it good for software applications.

Figure 1: The traditional model for web applications (left) compared to the Ajax model (right).
This approach makes a lot of technical sense, but it doesn’t makefor a great user experience. While the server is doing its thing,what’s the user doing? That’s right, waiting. And at every step in atask, the user waits some more.
Obviously, if we were designing the Web from scratch forapplications, we wouldn’t make users wait around. Once an interface isloaded, why should the user interaction come to a halt every time theapplication needs something from the server? In fact, why should theuser see the application go to the server at all?
How Ajax is Different
An Ajax application eliminates the start-stop-start-stop nature ofinteraction on the Web by introducing an intermediary — an Ajax engine— between the user and the server. It seems like adding a layer to theapplication would make it less responsive, but the opposite is true.
Instead of loading a webpage, at the start of the session, thebrowser loads an Ajax engine — written in JavaScript and usually tuckedaway in a hidden frame. This engine is responsible for both renderingthe interface the user sees and communicating with the server on theuser’s behalf. The Ajax engine allows the user’s interaction with theapplication to happen asynchronously — independent of communicationwith the server. So the user is never staring at a blank browser windowand an hourglass icon, waiting around for the server to do something.

Figure 2: The synchronous interaction pattern of a traditionalweb application (top) compared with the asynchronous pattern of an Ajaxapplication (bottom).
Every user action that normally would generate an HTTP request takesthe form of a JavaScript call to the Ajax engine instead. Any responseto a user action that doesn’t require a trip back to the server — suchas simple data validation, editing data in memory, and even somenavigation — the engine handles on its own. If the engine needssomething from the server in order to respond — if it’s submitting datafor processing, loading additional interface code, or retrieving newdata — the engine makes those requests asynchronously, usually usingXML, without stalling a user’s interaction with the application.
Who’s Using Ajax
Google is making a huge investment in developing the Ajax approach.All of the major products Google has introduced over the last year —Orkut,Gmail, the latest beta version ofGoogle Groups,Google Suggest, andGoogle Maps— are Ajax applications. (For more on the technical nuts and bolts ofthese Ajax implementations, check out these excellent analyses ofGmail,Google Suggest, andGoogle Maps.) Others are following suit: many of the features that people love inFlickr depend on Ajax, and Amazon’sA9.com search engine applies similar techniques.
These projects demonstrate that Ajax is not only technically sound,but also practical for real-world applications. This isn’t anothertechnology that only works in a laboratory. And Ajax applications canbe any size, from the very simple, single-function Google Suggest tothe very complex and sophisticated Google Maps.
At Adaptive Path, we’ve been doing our own work with Ajax over thelast several months, and we’re realizing we’ve only scratched thesurface of the rich interaction and responsiveness that Ajaxapplications can provide. Ajax is an important development for Webapplications, and its importance is only going to grow. And becausethere are so many developers out there who already know how to usethese technologies, we expect to see many more organizations followingGoogle’s lead in reaping the competitive advantage Ajax provides.
Moving Forward
The biggest challenges in creating Ajax applications are nottechnical. The core Ajax technologies are mature, stable, and wellunderstood. Instead, the challenges are for the designers of theseapplications: to forget what we think we know about the limitations ofthe Web, and begin to imagine a wider, richer range of possibilities.
It’s going to be fun.
March 13, 2005: Since we first published Jesse’sessay, we’ve received an enormous amount of correspondence from readerswith questions about Ajax. In this Q&A, Jesse responds to some ofthe most common queries.
Q. Did Adaptive Path invent Ajax? Did Google? Did Adaptive Path help build Google’s Ajax applications?
A. Neither Adaptive Path nor Google invented Ajax.Google’s recent products are simply the highest-profile examples ofAjax applications. Adaptive Path was not involved in the development ofGoogle’s Ajax applications, but we have been doing Ajax work for someof our other clients.
Q. Is Adaptive Path selling Ajax components or trademarking the name? Where can I download it?
A. Ajax isn’t something you can download. It’s anapproach — a way of thinking about the architecture of web applicationsusing certain technologies. Neither the Ajax name nor the approach areproprietary to Adaptive Path.
Q. Is Ajax just another name for XMLHttpRequest?
A. No. XMLHttpRequest is only part of the Ajaxequation. XMLHttpRequest is the technical component that makes theasynchronous server communication possible; Ajax is our name for theoverall approach described in the article, which relies not only onXMLHttpRequest, but on CSS, DOM, and other technologies.
Q. Why did you feel the need to give this a name?
A. I needed something shorter than “AsynchronousJavaScript+CSS+DOM+XMLHttpRequest” to use when discussing this approachwith clients.
Q. Techniques for asynchronous server communication have been around for years. What makes Ajax a “new” approach?
A. What’s new is the prominent use of these techniquesin real-world applications to change the fundamental interaction modelof the Web. Ajax is taking hold now because these technologies and theindustry’s understanding of how to deploy them most effectively havetaken time to develop.
Q. Is Ajax a technology platform or is it an architectural style?
A. It’s both. Ajax is a set of technologies being used together in a particular way.
Q. What kinds of applications is Ajax best suited for?
A. We don’t know yet. Because this is a relatively newapproach, our understanding of where Ajax can best be applied is stillin its infancy. Sometimes the traditional web application model is themost appropriate solution to a problem.
Q. Does this mean Adaptive Path is anti-Flash?
A. Not at all. Macromedia is an Adaptive Path client,and we’ve long been supporters of Flash technology. As Ajax matures, weexpect that sometimes Ajax will be the better solution to a particularproblem, and sometimes Flash will be the better solution. We’re alsointerested in exploring ways the technologies can be mixed (as in thecase of Flickr, which uses both).
Q. Does Ajax have significant accessibility or browsercompatibility limitations? Do Ajax applications break the back button?Is Ajax compatible with REST? Are there security considerations withAjax development? Can Ajax applications be made to work for users whohave JavaScript turned off?
A. The answer to all of these questions is “maybe”.Many developers are already working on ways to address these concerns.We think there’s more work to be done to determine all the limitationsof Ajax, and we expect the Ajax development community to uncover moreissues like these along the way.
Q. Some of the Google examples you cite don’t use XML at all. Do I have to use XML and/or XSLT in an Ajax application?
A. No. XML is the most fully-developed means ofgetting data in and out of an Ajax client, but there’s no reason youcouldn’t accomplish the same effects using a technology likeJavaScript Object Notation or any similar means of structuring data for interchange.
Q. Are Ajax applications easier to develop than traditional web applications?
A. Not necessarily. Ajax applications inevitablyinvolve running complex JavaScript code on the client. Making thatcomplex code efficient and bug-free is not a task to be taken lightly,and better development tools and frameworks will be needed to help usmeet that challenge.
Q. Do Ajax applications always deliver a better experience than traditional web applications?
A. Not necessarily. Ajax gives interaction designersmore flexibility. However, the more power we have, the more caution wemust use in exercising it. We must be careful to use Ajax to enhancethe user experience of our applications, not degrade it.
Jesse James Garrett is President and a founder of Adaptive Path. He is the author of the widely-referenced bookThe Elements of User Experience. Jesse’s other essays includeThe Nine Pillars of Successful Web Teams andSix Design Lessons From the Apple Store.
To get essays like this one delivered directly to your inbox, subscribe to ouremail newsletter. For more, check out ourblog.