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.
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.
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.
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.