Although the acronym AJAX is fairly straightforward, derived from Asynchronous JavaScript and XML, it's significant because it captures a paradigm shift in the delivery of Web page content.

The AJAX approach to Web content delivery speeds up the user interface. The long wait for an entire page to refresh from a Web server isn't necessary in an AJAX-based application. Only that part of a Web page that needs to be updated is altered, and the update is done locally, if possible, and asynchronously. The user can continue to interact with the Web page while JavaScript on the client minimizes interactions with the server, and information passing between client and server is done in the background.

For developers not yet using AJAX, any change to a Web page requires a full client/server interaction. For example, a request to insert a newly typed item into a list (say, an additional DVD selection into a Web shopping cart) requires a series of steps: after the new item name (the DVD title) is entered into a form, it's passed back to a server. The server then generates a new Web page. That page is transmitted back to the client, and the client's entire Web page screen gets refreshed. The URL at the top of the Web page reflects the transaction that has just occurred.

Interact locally

In contrast, in an AJAX-based Web application, the interaction looks like this: the user types a new item into an input box. JavaScript, running on the user's computer, inserts the item into the list and refreshes only a few lines of the Web page. The server is entirely cut out of the interaction, and the URL at the top of the Web page doesn't change.

Even if client/server interaction had been needed, say, to retrieve the latest discount price for the DVD, that could have been done interactively, and the response time of the user interface would have been more like that of a program running solely on the local machine.

The AJAX acronym was born on February 18, 2005, when it first appeared in a paper titled, Ajax: A New Approach to Web Applications, which was written by Jesse James Garrett, a founder of Web consultancy Adaptive Path. The term has generated a lot of buzz among developers and bloggers so far this year, but it's only the name that's new.

In his essay, Garrett points to existing Google applications -- Google Groups, Suggest, Maps and Gmail -- as examples of the new paradigm in Web interaction design. Google Maps doesn't jerk and stall as a user pans the field of view across an apparently limitless map. The older paradigm requires the user to click on an arrow in the requested panning direction, which is followed by an hourglass hiatus while the map server creates the desired view and downloads it to the local machine.

The following technologies and protocols used in AJAX had been around for a while before Garrett specified them in his essay:

• XHTML and Cascading Style Sheets (CSS) for presentation.
• Document Object Model for dynamic display.
• XML and Extensible Stylesheet Language Transformations for data interchange.
• Microsoft's XMLHttpRequest for asynchronous client/server interaction.
• JavaScript to run commands on the client machine.

Until recently, however, some crucial pieces weren't in place to bring the technologies together. As Adam Bosworth, vice president of engineering at BEA Systems, wrote in a recent blog on the subject, "The physics didn't work in 1997." Without the wide adoption of broadband, Bosworth points out, downloading the required JavaScript for local control (often as much as 10,000 to 20,000 lines of code) took too long.

In addition, until a few years ago, processors ran too slowly for JavaScript. Even if the physics had worked, until recently the same code couldn't have run on all Web browsers, Bosworth says.

Finally, or perhaps most important, in Bosworth's estimation, personal applications like Google Maps and Gmail were in the minority of Web applications and their use was less widespread five or six years ago than they are today.

Some limits

Not all applications may be right for the AJAX approach. Sceptics frequently cite "breaking the Back button" as a serious problem. Because AJAX allows Web pages to be modified locally and/or incrementally, clicking on the Back button doesn't necessarily return a user to the previous page. The Back button may take the user all the way back to the beginning of a long interaction -- the one specified by the URL shown at the top of the Web page.

For the same reason, the URL at the top of the Web page doesn't completely specify the contents of a page, so it may be impossible to bookmark desired pages or share URLs so that others may see the same Web content. And asynchronous updates, as blogger Alex Bosworth (son of Adam Bosworth) and others have pointed out, mean that a Web page could adjust its shape, layout or length unexpectedly.

Despite those drawbacks, AJAX has generated real excitement with its promise of more-responsive Web interactions. Garrett ends his essay with this Utopian vision: "The biggest challenges in creating Ajax applications are not technical. . . . The challenges are for the designers of these applications: to forget what we think we know about the limitations of the Web, and begin to imagine a wider, richer range of possibilities."

AJAX: MVC Redux

Some people who follow development trends bristle at the suggestion that AJAX is anything new, despite the recent coinage of the term. For them, AJAX is just the most recent incarnation of a model-view-controller (MVC) architecture for building applications. The roots of MVC can be traced back to 1979, when Trygve Reenskaug, a researcher working on the Smalltalk language at Xerox's Palo Alto Research Centre, first described the architectural pattern and its benefits.

MVC separates an application's data model, user interface and control logic into three distinct components, or objects. This means that modifications to the view component (usually the user interface) can be made with minimal impact to the data model. The data model is the domain-specific representation of the information on which the application will operate.

The controller mediates between the data model and the view. It responds to events, which are usually actions by users, and changes the view or model as appropriate.

The primary benefit of the MVC approach is that it increases the responsiveness of the view component while maintaining the stability of the data model -- no mean feat, given the event-driven characteristics of the modern graphical user interface.

Since it requires the separation of the model and the controller from the view component, the MVC design also promotes platform independence for programs. The programmer can implement the data model and the controller in a cross-platform language like C or C++. The toughest part of porting the application to a new operating system then becomes redesigning the view. Use of the OS-specific language is then limited to controller notification of user events and changes in the data model.

MVC and its offspring, such as AJAX, are viewed by many as the most promising means of unraveling the complexities of Web application development.