(Post 22/11/2005) 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…

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

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.

Comparison to traditional Web applications

Ajax applications look almost as if they reside on the user's machine, rather than across the Internet on a server. The reason: pages get updated, not 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 responds by sending a new web page back. Because the server must submit a 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, usually using SOAP or some other XML-based web services dialect. On the client, JavaScript processes the web server response. 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.

(Both images come from the Adaptive Path article by Jesse James Garrett, cited in the External Links section below.)

As an example of how Ajax works, consider a photography website that allows users to enter captions. With a traditional web application, the entire page including the image would need to be refreshed. With Ajax technologies, DHTML might replace just the caption text, resulting in a noticeably smoother transaction. (This example is actually how Flickr allows users to change photo captions.)

Adoption

The techniques have been in use since around 1998. The first component to allow client-side script to issue HTTP requests (XMLHTTP) was written by the Outlook Web Access team, which is a part of Microsoft Exchange Server, and it soon became a part of the Internet Explorer 4.0 installation [1]. Some observers consider the Outlook Web Access to be the first successful commercial Ajax application and others soon followed including Oddpost's web mail product. However, in early 2005 a number of seminal events have popularised the technique. First, Google used asynchronous communication as a basis for prominent interactive applications including Google Groups, Google Maps, Google Suggest and Gmail. Second, the name Ajax was coined in Ajax: A New Approach to Web Applications, which quickly came into popular use and helped raise consciousness of the technique. In addition, Mozilla/Gecko support of the feature had matured to the point where it was widely and easily usable.

Pros, cons and criticism

The biggest advantage of using Ajax technologies is that data can be manipulated without having to render the entire page again in the web browser. This allows web applications to respond more quickly to many types of user interaction and to avoid repeatedly sending unchanged information across the network. Also, because AJAX technologies are open, they are supported in all Javascript enabled browsers regardless of operating system. Competing technologies like Macromedia's Shockwave have plugins for Linux only recently.

While no browser plug-in is required, Ajax requires users to have JavaScript enabled in their 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.

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

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). Returning to the previous state may not be possible when a page is updated dynamically, since browsers typically record only static page visits in their history lists. The distinction between a static page, loaded in its entirety, and a page which has been modified dynamically 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 the Ajax element on the visible web page; the Dojo toolkit allows tracking of Ajax requests 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.

However, we can also argue that traditional web applications made using standard HTML do not handle the back button correctly either. Imagine a user deleting an email in a webmail software; the back button would again show that very email, but in reality it has been deleted already. As opposed to standard HTML, Ajax can even help avoid such problems by dynamically changing the browser history.

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 [2], smart preloading of data [3], and proper handling of the XMLHttpRequest object [4] users might experience delay in the interface of the web application, something which users might not expect or understand. [5] The use of visual feedback to alert the user of background activity and/or preloading of content and data are often suggested solutions to latency issues with AJAX.

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

Accessibility

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 Mail, Google Maps, and Flickr. These high-profile examples of Ajax usage demonstrate the flexibility and utility of the web programming model. Google's competitors have recently released similar Ajax-based websites (such as America Online's AIM Mail and Microsoft's Virtual Earth)

Search engine / deeplinking

Several approaches are available for making your Ajax application accessible to search engines; these approaches differ in the level of indexing which is obtainable, and how this is achieved. For certain sites, it is not necessarily a requirement that every part of the site can be indexed by search engines. A site which provides a web-based e-mail service, for example, does not require every single piece of information on the site to be indexed by a search bot. Other sites, however, do require that every piece of information can easily be found and indexed by search engines. A web site with information about the courses provided by a university is one example. The following strategies can be used to get a SPI indexed by search engines:

Browsers that support Ajax

Example applications

External links

Articles

Tutorials/Examples

Portals

Podcasts

Forums

Presentations

Libraries/Scripts

Libraries/Scripts with server-side integration

Multiplatform

ColdFusion

.Net

Java

Perl

PHP

Python

Ruby

(theo Wikipedia)