Ajax: Pinning It Down

One of the interesting things about Ajax is that there is some confusion and even a little disagreement as to what Ajax really is. We know that it is important and that it's very popular; heck, we even changed the name of this book from previous editions to hitch onto Ajax's popularity. So here is our take on what Ajax is and isn't, and what we mean when we use the term.

First, a little history. In February 2005, Jesse James Garrett, a founder of Adaptive Path (a Web interface and design shop in San Francisco), coined the term Ajax in an article on their site. He said Ajax was shorthand (but not an acronym) for "Asynchronous JavaScript and XML." You can read the article for yourself at www.adaptivepath.com/publications/essays/archives/000385.php (Figure 15.1).

Figure 15.1. This is the article that launched a zillion Ajax sites.

[View full size image]

According to Garrett, Ajax is not in itself a new technology; it's a technique that combines several long-standing Web technologies:

Using XHTML and CSS for structure and presentation
Displaying and manipulating pages using the Document Object Model
Using the browser's XMLHttpRequest object to transfer data between the client and the server
Using XML as the format for the data flowing between the client and server
And finally, using JavaScript to dynamically display and interact with all of the above

An Ajax application places an intermediary between the user and the server. This Ajax engine (also known as the JavaScript part of a Web page) provides an interface to the user (in concert, of course, with XHTML and CSS), and if a user action doesn't require a request to the server (for example, displaying data that is already local), the Ajax engine responds. This allows the browser to react immediately to many user actions and makes the Web page act with the snappiness we've come to expect from our desktop programs. If the user action does require a server call, the Ajax engine performs it asynchronously, that is, without making the user wait for the server response; the user can continue to interact with the application, and the engine updates the page when the requested data arrives. The important part is that the user's actions don't come to a screeching halt while waiting for the server.

As the technique evolved, not all of the pieces had to be in place to call something an Ajax application, and this is where the confusion and disagreements set in. In fact, even the authors disagree about this:

Tom says, "I'm fine with just manipulating the page with the DOM, XHTML and CSS, and JavaScript and calling it Ajax. There are tons of effects that people are referring to as Ajax, and the whole look of modern sites has changed because of this approach. The change from the static Web to the dynamic Web page, which is sometimes called Web 2.0, owes its look and feel to the Ajax approach, whether or not there's a server call behind the scenes. Maybe calling it Ajax won't please the purists, but it's good enough for me."

Dori, who's the real JavaScript programmer in the family, says: "To call it Ajax, you need to use XMLHttpRequest and transfer some data between the client and server. Otherwise, what's so new about it?"

Dori's writing the code, so for the most part in this chapter we're sticking to her sensibilities as to what an Ajax application is and what it should do. But in the next chapter, we'll show you how to add some great (but still useful, not just flashy) Web 2.0style eye candy to your sites.

Now, let's talk a little about what's not Ajax. Because you can do some cool visual effects on Web pages using Ajax, some people think that Ajax is anything you can do that looks good on a page, leading them to refer to things like interfaces made in Macromedia Flash as "Ajax." But just saying it doesn't make it so. Ajax is not about loading up your sites with cute user interface widgets and adding user interface tweaks that are cool but that change or break behaviors that people are used to with Web pages.

That leads us to problems with Ajax, and they can be significant. For example, to work correctly, an Ajax site needs to be running in a modern browser (for a list, see the back cover of this book). It also requires JavaScript. So what do you do about people using older browsers or who have turned JavaScript off? Or what about disabled users, or people who may be browsing your site with limited-capability handheld devices such as mobile phones or PDAs? The answer is that you must write your sites to degrade gracefully, meaning that users with less-capable browsers get a subset of your site's functionality, or, at the minimum, get a meaningful error message explaining why they can't use your site.

Another potential problem with Ajax applications is that they may break the expected behavior of the browser's back button. With a static page, users expect that clicking the back button will move the browser to the last page it loaded. But because Ajax-enabled pages are dynamically updated, that might not be a valid expectation. There are solutions for the "back button problem," and before you dive wholeheartedly into Ajax, you should take the problem and its solutions into account.

Additionally, Ajax is not dependent on specific server-side technologies. There are a number of companies that are using the Ajax boom to try to sell their own server-side solutions, and that's what they're in business to dobut there's no reason why their products are required. So long as what's on the back end is something that your JavaScript can read (XML, ideally), you're fine. Just because the guys in the snappy suits (cough IBM cough Sun cough) want to hitch their buzzword-compliant products to Ajax's success in order to get you to buy doesn't mean that you have to fall for it.