Asynchronous JavaScript and XML, or Ajax

Asynchronous JavaScript and XML, or Ajax, is a web development technique for creating interactive web applications using a combination of:

  • XHTML (or HTML) and CSS for marking up and styling information
  • The Document Object Model manipulated through JavaScript to dynamically display and interact with the information presented
  • The XMLHttpRequest object to exchange data asynchronously with the web server. (XML is commonly used, although any format will work, including preformatted HTML, plain text, JSON and even EBML). In some Ajax frameworks and in some situations, an IFrame object is used instead of the XMLHttpRequest object to exchange data with the web server.

Like DHTML, LAMP, or SPA, Ajax is not a technology in itself, but a term that refers to the use of a group of technologies together. In fact, derivative/composite technologies based substantially upon Ajax, such as AFLAX, are already appearing.

For a number of tasks, only small amounts of data must be transfered between the client and the server, allowing a number of Ajax applications to perform almost as well as (interpreted) applications executed completely on the user’s machine. This has the effect that pages need only be updated in the user’s browser, rather than having to be entirely refreshed. “Every user’s action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead?, wrote Jesse James Garrett, in the essay that first defined the term. “Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.?

Traditional web applications essentially submit forms, completed by a user, to a web server. The web server does some processing, and responds by sending a new web page back. Because the server must send a whole new page each time, applications run more slowly and awkwardly than their native counterparts.

Ajax applications, on the other hand, can send requests to the web server to retrieve only the data that is needed, and may use SOAP or some other XML-based web services dialect. On the client, JavaScript processes the web server response, and may then modify the document’s content through the DOM to show the user that an action has been completed. The result is a more responsive interface, since the amount of data interchanged between the web browser and web server is vastly reduced. Web server processing time is also saved, since much of it is done on the client.

The earliest form of asynchronous remote scripting, Microsoft’s Remote Scripting, was developed before XMLHttpRequest existed, and made use of a dedicated Java applet. Thereafter, remote scripting was extended by Netscape DevEdge at around 2001/2002 by use of an IFRAME instead of a Java applet.



Pros, Cons and Criticism



Due to the fact that Ajax applications are mostly executed on the user’s computer, they can perform a number of tasks without their performance being limited by the network. This permits the development of interactive applications, in particular reactive and rich graphic user interfaces.


Ajax applications rely on technologies already available in the browser, without having to load additional layers such as the heavy-weight Java Virtual Machine or the lighter Flash plugin. The use of Ajax technologies incurs very little cost in terms of memory usage.


Ajax applications target a (relatively) well-documented platform, implemented by all major browsers on most existing platforms. While it is uncertain that this compatibility will resist the advent of the next generations of browsers (in particular, Firefox 2 and Internet Explorer 7), at the moment, Ajax applications are effectively cross-platform.

While the Ajax platform is more restricted than the Java platform, current Ajax applications effectively fill part of the one-time niche of Java applets: extending the browser with portable, lightweight mini-applications.

Cons and Criticism

Usability Criticisms

One major complaint voiced against the use of Ajax in web applications is that it might easily break the expected behavior of the browser’s back button (see Jakob Nielsen’s 1999 Top-10 New Mistakes of Web Design). The different expectations between returning to a page which has been modified dynamically versus the return to a previous static page might be a subtle one. Users generally expect that clicking the back button in web applications will undo their last change and in Ajax applications this might not be the case. Developers have implemented various solutions to this problem, most of which revolve around creating or using invisible IFRAMEs to invoke changes that populate the history used by a browser’s back button. Google Maps, for example, performs searches in an invisible IFRAME and then pulls results back into an element on the visible web page; it is possible to track user behaviour via callbacks which are called whenever the back button is pressed, restoring the application state that existed at the time.

A related issue is that the use of dynamic web page updates makes it difficult for a user to bookmark a particular state of the application. Solutions to this problem have likewise begun to appear, many of which use the URL fragment identifier (commonly known as the anchor, or the portion of the URL after the ‘#’) to keep track of, and allow users to return to, the application in a given state. (Many browsers allow JavaScript scripts to update the anchor dynamically, which allows the Ajax application to update it in parallel with the contents of the display.) These solutions also address many of the issues related to lack of back button support.

Response-time concerns

Network latency — or the interval between user request and server response — needs to be considered carefully during Ajax development. Without clear feedback to the user [1], smart preloading of data [2], and proper handling of the XMLHttpRequest object [3] users might experience delay in the interface of the web application, something which users might not expect or understand. [4] The use of visual feedback to alert the user of background activity and/or preloading of content and data are often suggested solutions to these latency issues.

JavaScript must be enabled

While no browser plug-in is required for Ajax, it requires users to have JavaScript enabled in their browsers.

Some browsers do not support JavaScript or ActiveX. Security settings might cause Internet Explorer to not support Ajax (e.g.: JavaScript might be disabled). This is comparable to the early days of DHTML when it was not supported by many browsers.

As with DHTML applications, Ajax applications must be tested rigorously to deal with the quirks of different browsers and platforms. A number of programming libraries have become available as Ajax has matured that can help ease this task. Likewise, techniques have been developed to assist in designing applications which degrade gracefully and offer alternative functionality for users without JavaScript enabled.

Criticism of the name Ajax

There have been some critics of the term Ajax, claiming that Adaptive Path (the consultancy firm that coined the term [5]) or other proponents are using it as a marketing vehicle for previously-used techniques [6] [7] [8] [9].


Using Ajax technologies in web applications provides many challenges for developers interested in adhering to WAI accessibility guidelines. Developers need to provide fallback options for users on other platforms or browsers, as most methods of Ajax implementation rely on features only present in desktop graphical browsers.

Web developers use Ajax in some instances to provide content only to specific portions of a web page, allowing data manipulation without incurring the cost of re-rendering the entire page in the web browser. Non-Ajax users would optimally continue to load and manipulate the whole page as a fallback, allowing the developers to preserve the experience of users in non-Ajax environments (including all relevant accessibility concerns) while giving those with capable browsers a much more responsive experience.

Many popular applications using the concept have been created, including Google Maps and GMail, Yahoo’s Flickr, America Online’s AIM Mail, 24SevenOffice and Microsoft’s Virtual Earth. These high-profile examples of Ajax usage demonstrate the flexibility and utility of the web programming model.

Server-Side Approaches

One of the critical questions in programming with Ajax is determining the client-server architecture. In theory, Ajax is server independent. In practice, the server-side technology chosen has a significant impact on the programming choices that are available. Server-side Java[10], for example, provides a mature server-side technology with rich thread support as well as strong support from the open source community. Ruby, especially Ruby on Rails, has been reported to have strong productivity benefits. PHP also has strong open source support but is not as strong as Java as far as thread support and has a growing reputation of being difficult to maintain. Perl, which was once very popular, has been declining in its usage. Python is a powerful scripting language that is well respected but does not seem to be used as frequently as Java or PHP (Google was built on Python[11]). Server-side JavaScript is also an interesting alternative which seems to be growing in usage. Microsoft .NET as a platform for Ajax is also growing, but doesn’t yet have the strong open source support (except with use under Mono) that Java and PHP have. In addition, there are technologies such as Jython (python), Rhino (javascript), and JRuby (Ruby) that provide the productivity advantages of scripting languages but run on top of server-based Java.

Search engine / deeplinking

Several approaches are available for making Ajax applications accessible to search engines; these approaches differ in the level of indexing which is obtainable, and how this is achieved. For cert

Links and Resources:

useful links page: