Ajax (programming)

Ajax (also known as AJAX), shorthand for "Asynchronous JavaScript and XML", is a web development technique for creating interactive web applications. The intent is to make web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user requests a change. This is meant to increase the web page's interactivity, speed, and usability.

Pros and cons

Pros

User interface

The most obvious reason for using Ajax is an improvement to the user experience. Pages using Ajax behave more like a standalone application than a typical web page. Clicking on links that cause the entire page to refresh feels like a "heavy" operation. With Ajax, the page often can be updated dynamically, allowing a faster response to the user's interaction. While the full potential of Ajax has yet to be determined, some believe it will prove to be an important technology, helping make the Web even more interactive and popular than it currently is.

Bandwidth usage

By generating the HTML locally within the browser, and only bringing down JavaScript calls and the actual data, Ajax web pages can appear to load relatively quickly since the payload coming down is much smaller in size. An example of this technique is a large result set where multiple pages of data exist. With Ajax, the HTML of the page, e.g., a table structure with related TD and TR tags can be produced locally in the browser and not brought down with the first page of the document.

In addition to "load on demand" of contents, some web based applications load stubs of event handlers and then load the functions on the fly. This technique significantly cuts down the bandwidth consumption for web applications that have complex logic and functionality.

Separation of data, format, style, and function

A less specific benefit of the Ajax approach is that it tends to encourage programmers to clearly separate the methods and formats used for the different aspects of information delivery via the web. Although Ajax can appear to be a jumble of languages and techniques, and programmers are free to adopt and adapt whatever works for them, they are generally propelled by the development motive itself to adopt separation between the following:

1. Adopt separation between the raw data or content to be delivered - which is normally embedded in XML and sometimes derived from a server-side database.
2. Adopt separation between the format or structure of the webpage - which is almost always built in HTML (or better, XHTML) and is then reflected and made available to dynamic manipulation in the DOM.
3. Adopt separation between the style elements of the webpage: everything from fonts to picture placement are derived by reference to embedded or referenced CSS.
4. Adopt separation between the functionality of the web page which is provided by a combination of
   1. Javascript on the client browser (also called DHTML),
   2. Standard HTTP and XMLHttp for client-to-server communication, and
   3. server-side scripting and/or programs using any suitable language preferred by the programmer to receive the client's specific requests and respond appropriately.

Cons

Browser integration

The dynamically created page does not register itself with the browser history engine, so triggering the "Back" function of the users' browser might not bring the desired result.

Developers have implemented various solutions to this problem. These solutions can involve 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. The World Wide Web Consortium (W3C) did not include an iframe element in its XHTML 1.1 Recommendation; the Consortium recommends the object element instead.

Another issue is that dynamic web page updates make it difficult for a user to bookmark a particular state of the application. Solutions to this problem exist, many of which use the URL fragment identifier (the portion of a URL after the '#'^[6][7]) to keep track of, and allow users to return to, the application in a given state. This is possible because many browsers allow JavaScript to update the fragment identifier of the URL dynamically, so that Ajax applications can maintain it as the user changes the application's state. This solution also improves back-button support. It is, however, not a complete solution.

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,^[8] smart preloading of data and proper handling of the XMLHttpRequest object, users might experience delay in the interface of the web application, something which they might not expect or understand. Additionally, when an entire page is rendered there is a brief moment of re-adjustment for the eye when the content changes. The lack of this re-adjustment with smaller portions of the screen changing makes the latency more apparent. The use of visual feedback (such as throbbers) to alert the user of background activity and/or preloading of content and data are often suggested solutions to these latency issues.

Microsoft's Ajax Extensions addresses this network latency issue by offering the UpdateProgress control which allows the developer to alert the user that the page is being updated.

Search engine optimization

Websites that use Ajax to load data which should be indexed by search engines must be careful to provide equivalent data at a public, linked URL and in a format that the search engine can read, as search engines do not generally execute the JavaScript code required for Ajax functionality. This problem is not specific to Ajax, as the same issue occurs with sites that provide dynamic data as a full-page refresh in response to, say, a form submit (the general problem is sometimes called the hidden web).

JavaScript reliability

Ajax relies on JavaScript, which may be implemented differently by different browsers or versions of a particular browser. Because of this, sites that use JavaScript may need to be tested in multiple browsers to check for compatibility issues. It's not uncommon to see a JavaScript code written twice, one part for IE, another part for Mozilla compatibles. (see also Cross-platform web design). The level of IDE support for JavaScript is exceptionally poor.

An issue also arises if the user has switched off JavaScript support in the browser, thus disabling the functionality of the page.

This is about Programming Web 2.0

Introduction

A profound change is happening on the cutting-edge of web development: we are relinquishing control of information. No longer are sites working independently from each other; no longer is information sitting in isolation with no interaction between sites. Rather, the best web programmers are now creating sites that allow information to be reused anywhere.

This means you can include the BBC’s latest news headlines on your site. It means people can keep track of your job vacancies on their desktop. It means instead of having a static map on your contact page you can include a map from Google that can be annotated, dragged around, and zoomed in and out. Ultimately, it means people will no longer need to get your information directly from your web site. That may sound terrifying to some but once you embrace this new paradigm its benefits become obvious. Welcome to the world of Web 2.0.

Web 2.0 can be summarised thus:

• the web is a platform: just as software is released for Microsoft Windows so to will software be released for the web;
• data is the focus of everything;
• build an architecture of participation: that is, systems are designed for user contribution;
• sites are composed of features pulled from distributed and independent developers;
• it has lightweight business models; and
• continual, automatic — almost invisible — software updates rather than a software adoption cycle.

The technologies that allow this to happen already exist; the most important being XML-based syndication and aggregation using RSS and Atom, rich-application support (the web’s current beau in this field is AJAX), and using URLs as a command-line. The last of these will be the focus of a forth-coming paper; for the rest of this one the focus shall be on the first three.