|
|
|
|
 |
Asynchronous JavaScript And XML, or Ajax (pronounced as a word, not as individual letters), 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.
Contents |
The earliest form of asynchronous remote scripting, Microsoft's Remote Scripting, was developed before XMLHttpRequest existed, and made use of a dedicated Java applet. The web development community, first collaborating via the microsoft.public.scripting.remote newsgroup and later through blog aggregation, subsequently developed a range of techniques for remote scripting in order to enable consistent results across different browsers. Early examples are the IFRAME-based JSRS library from 2000, introduction of the Image/Cookie technique in 2000, the JavaScript on Demand technique in 2002. In 2002, a user-community modification to Microsoft Remote Scripting was made to replace the Java applet with XMLHttpRequest.
Remote Scripting Frameworks such as ARSCIF surfaced in 2003 not long before Microsoft introduced Callbacks in ASP.NET
Some early articles promoting Remote Scripting techniques:
Since XMLHttpRequest is now implemented across the majority of browser marketshare, the alternative techniques are now less popular, however they are still used where wide compatibility, small implementation, or cross-site access are required.
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 target a 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), 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.
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 state 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.
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.
While no browser plug-in is required for Ajax, it requires users to have JavaScript enabled in their browsers. This applies to all browsers that support Ajax except for Microsoft Internet Explorer which additionally requires ActiveX to be enabled along with ActiveScript. The XMLHTTPRequest object used in Internet Explorer is ActiveX. Security settings might cause Internet Explorer to not support Ajax (e.g.: ActiveScript or ActiveX might be disabled). It is possible to use inline frames (IFRAMEs) to avoid this ActiveX problem.
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.
There have been some critics of the term Ajax, claiming that Adaptive Path (the consulting 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.
The common approach to apply Ajax usually involves a lot of programming in JavaScript. Frameworks are then aimed to provide ready-to-use UI (e.g., in HTML or XUL) widgets and libraries to make programming in JavaScript easier.
The major advantage of the declarative approach is that non-programmers are allowed to define user interfaces with HTML-like markup language. The disadvantage is that pages are becoming harder and more obscure to design and maintain, as they become more sophisticated.
(Note that this is a general list, and support of Ajax applications will depend on the features the browser supports.)