Ajax is not a technology in itself, but a term that refers to the use of a group of technologies together.

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.

Photo credit: Jesper Noer

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.
(Source: Wikipedia)

Here is Eddie Traversa excellent introduction to his Ajax Tutorial, What Is It Good For?, which not only provides an excellent introduction for the layman, but further dives into analyzing specific coding techniques and examples:

To my way of thinking, Ajax is more a natural progression from an existing set of techniques as opposed to being something completely brand new.

Yet within that progression, things are markedly different than in previous years in a couple of key areas:

• Ajax provides a mechanism to mix and match xml with xhtml.
• Ajax significantly reduces having to continually fetch things from a server (remote iframe scripting is reasonably comparable here).
• Ajax overcomes some speed bottlenecks that traditional Web development has fallen prey too. In most instances an Ajax based site will load quicker than a comparable traditional Web site.
• When done well, Ajax significantly reduces initial load times.

Before proceeding, it should be noted that Ajax isn't a panacea. It has some problems that it needs to overcome as it continues to mature. But it is a promising field to be involved within and as the years roll on, it probably will greatly affect the way we think about building Web pages and Web applications.

It also needs to be clear that Ajax isn't a technology as such but rather is a technique that combines well with other technologies and techniques. For example, XML, DHTML, CSS, XHTML.

In fact, Ajax really is DHTML with the xmlhttprequest object thrown in. It is amazing to think how one object can change the whole playing field.

As things currently stand in the Ajax field, we almost have two extremes going on.

At one end of the continuum we have developers building all sorts of complicated JavaScript tags that in most instances are unnecessary and are overkill.

At the other end of the scale we have these little examples floating around the Web that demonstrate how to load XML into a document or do some Ajax-centered form processing.

While both ends of the spectrum have a part to play in the progression of the Web, I am not convinced that the principles of Ajax and how they can best be leveraged by a developer have been conveyed as well as they may have.

Ajax itself is a technique, but to use the technique effectively one must become familiar with the philosophy behind the technique.

In other words, it is not just the use of the technique that is important, but rather developing a different mindset and approach to Web development that is central.

To date, I have mentioned the term Ajax a number of times but have not described the central object that makes Ajax, Ajax.

At the heart of Ajax are the xmlhttprequest object and its Microsoft's ActiveX equivalent.

It is this object that allows data to be transferred asynchronously.

In case you are not clear what asynchronous means, it is the ability to handle processes independently from other processes. Synchronous which is the opposite of asynchronous, then means that processes are dependent upon other processes. To illustrate let us use a classical Web page scenario.

Assume we have page A and on this page we have a number of elements, including a couple of script and style tags. With synchronous data transfer the script tag needs to be parsed before the next element is parsed. In this way then the next element to be parsed by the browser is dependent upon the script tag being parsed first. Effectively we are creating a bottleneck of one connection between Web page and browser. Style tags and link elements in the head section of the document create the same bottleneck effect. They have to be parsed one at a time before other page elements can download.

Once they have been parsed then the elements in the body section can use concurrent connections to help speed up the download process. For example, most servers handle between 2 to 4 concurrent connections between web page and browser.

Consequently, this means that 2 to 4 images or other page elements can load concurrently. Yet before that process starts what is between the head tags have to be parsed first, which can considerably delay the loading of web pages.

Most particularly if you are using multiple CSS and JavaScript tags.

Nearly every Web page and blog on the internet uses this method. It isn't hard to see why this may be a problem in terms of increasing page load speeds.

Asynchronously loading methods differ from this scenario because the loading processes are handled independently of each other and to a significant degree overcomes the bottle of traditional Web page design.

The whole gist of this technique is to use minimal JavaScript initially and then push all the head related tags, including the rest of the JavaScript, CSS etc tags through an xmlhttprequest object.

This method uses multiple connections rather than the single one that most traditional Web pages use and consequently speeds things up considerably.

Are you into trying some Ajax code out?

Eddie Traversa takes you into a fully documented walkthrough Ajax coding tutorial. Check it out...

About the author:

Eddie Traversa has been developing for the web for over 10 years, has written various articles on JavaScript and DHTML, and hosts a developers resource site at http://www.dhtmlnirvana.com/