Introduction

I'm never been one to start by uselessly stating what an acronym stands for, but since it may be helpful in this case, I'll break my own rule this once: AJAX ("Ajax") stands for Asynchronous JavaScript with XML. It's the future of web development and for many, including myself, it's been what web application development has been about for years.

You can think of Ajax web development as being the quantum mechanics of the web development world. The paradigms are different, the players are different, and even the rules are different. Traditionally a web application goes through a "roundtrip" to process and update data to the user. That is, the web browser sends the server a request and then an entirely new page loads to complete a "roundtrip." This is a synchronous processing method where the client and server take turns I a synchronous manner. Ajax, by definition, thanks to the 'A', is asynchronous, so you no longer have to wait for an entirely new page. The user sends a request, goes about his or her other business and then receives an update on what he or she requested. No more waiting for just one thing to be completed at a time. To avoid the needless "roundtrips", the user just sends a request on the fly to the server for some specific data and receive only the data he or she requested without the waste of getting an entirely new page.

While I have been developing Ajax applications since before this millennium, it has only recently become popular with the general web population. The most obvious example of an Ajax application is Google's Gmail. People often ask me why Gmail is so different than other online message/e-mail services. In my answer there are of course allusions to the life-saving concepts of labels instead of folders and conversations instead of e-mails, but also there is my answer regarding its use of asynchronous technology.

In Hotmail and Yahoo! Mail, when you want to, for example, mark a message or series of messages as read you have to press a button and wait for the server to complete a "roundtrip." That is, you have to wait for the server to send you an entirely new updated page. In Gmail, with its use of Ajax technology, there is no roundtrip. So, while the other e-mail services refresh the entire screen when a user presses the button, thus sending a tremendous amount of redundant information to the user, Gmail works with only the appropriate components. In this case, it would send a message to the server telling it that you want to mark a series of messages as read and the server will send your browser back a confirmation all without a roundtrip and alter the screen accordingly. This process saves bandwidth and therefore, time.

That is just one example of a popular Ajax application. Another great example is Google Maps. I've never personally talked to a person who wasn't absolutely amazed at this website (ok, it's an application, but most people call it a website.) You can navigate all around the United States on just one little screen. The application almost never does a "roundtrip", thus gives the user a lightening fast user experience.

But, Ajax isn't just about asynchronous processing to allow for lightening fast applications and websites. The next part is the JavaScript portion. JavaScript is often called the most misunderstood programming language in existence. I would definitely have to agree. When most web developers think of JavaScript they think of data validation or some sort of form processing to allow simple messages like 'Sorry, but your phone number doesn't seem to be in the correct format.' Or a simple message like in Yahoo! Mail 'Are you sure you want to empty the trash box." Some with regard to JavaScript may even think of some sort of dynamic presentation like changing the text on the screen. But JavaScript is more than a simple scripting system, it's an extremely power programming language which brings to the table a tremendous amount of possibilities. This isn't just true for JavaScript as defined in the past 13 years of it's life, but more so future versions like ECMAScript version 4 that is soon to be public with the release of Firefox 1.1 due in the third quarter of 2005.

Going back to the example of online mail service, when you hit a reply button in Hotmail or Yahoo! Mail, a request is sent and, as before, a tremendous amount of redundant information is sent back to the user to create an entirely new screen just for the message response. In Gmail, however, you simply click in the reply box. Done. It immediately creates a new e-mail around the mouse cursor. It does this by using JavaScript to dynamically alter the page is drastic ways. What may take 4 seconds in Yahoo! Mail and Hotmail, now takes less than a second with Gmail. So, if you are a dial-up user, you need to be using Gmail. Well, actually, if you are a human, you need to be using Gmail. This is all thanks to Ajax technology.

Using JavaScript, an expert web developer could theoretically create entire web solutions without ever touching a single line of server-side code. With Firefox a developer could even utilize Firefox's built in SOAP and WSDL capabilities to do all necessary web service processing. Then a developer could use JavaScript to update all necessary pieces of the application with the new data retrieved by the web service. Of course in practice you would have a middle layer of C#, PHP, JSP or whatever to do your server-side accessing to play the middle-man role between the client-side application and the database and file servers. Put another way, Ajax allows you to keep your middle layer as small and efficient as possible.

JavaScript allows you to access and manipulate virtually any object on of off screen. It's your key to deploying web-based desktop-like applications. Soon, in ECMAScript version 4, you will be able to work with things like XML with incredible easy. It's already no problem to work with XML and you can currently use JavaScript to open a local or remote XML file to allow data access served by your middle layer, but soon there will a new syntax and language structure which will allow for more intuitive and more powerful XML processing than ever seen in any other technology. You can thank Firefox 1.1 for making this new technology, ECMAScript version 4, something that we can all use publicly on the web. It's actually no coincidence that JavaScript works so well with XML. The last letter of the AJAX acronym is the X which represents XML.

When some people think of XML, they think of a data format and when some people think of HTML they think of a presentation format. Well, while it may sound like I'm building up to a correction, these theories are actually absolutely correct. XML is for data and HTML is for presentation. But with Ajax and in the world of modern web-standards, there is a technology which combines the two. Thus enters XHTML.

XHTML combines XML and HTML to create something that is not data, and definitely not presentation, but creates rather a page structure. XML by itself cannot render data and therefore cannot solely be used to put controls (i.e. text boxes, buttons, etc…) on the screen and HTML is actually unparsable by today's standards, so it can't be used in strict production environments. XHTML combines the visual aspect of HTML with the parsability of XML to create the new canvas used in modern websites and web applications. With the various types of XHTML, a developer can choose that which best suits his or her own needs at the moment. It's actually a little known fact that there are two primary types of XHTML: one that is text based, which is really just HTML written in XML, and one that is application based, which is true XHTML.

In modern Ajax development when you are creating applications you should seek to use the applications version of most technologies. Why? The text version is not parsed like the application version. Deployment of applications requires a way of mechanical testing. Usually this is done with a compiler, which will check your code for errors, but what about uncompilable things like HTML? While with HTML and text based XHTML, you have to do this manually, by using the application based version XHTML you can parse and validate your code just like any compiler would. That is, no Java or C++ application would ever run with poor syntax because the compiler will prevent it from ever being deployed. So is the same with application based XHTML. If your XHTML code is improper, that is, has poor syntax or other problems, then it will not run. You will be able to catch your errors much earlier and you are forced to take XHTML errors as seriously as you would Java or C++ compiler errors. This allows you to ensure that your web applications are proper, thus bringing you another step closer to having web application development really feel more like windows development…and the quality assurance team will love you for it.

While that exhausts the acronym, there are more parts to Ajax. The one that seems to be the most important to many people, including myself, is one that didn't receive a letter in the acronym and that's web-standards. Some people think that web-standards bring you the ability to write standardized code that will work anywhere. Well, anyone who has been a web developer for more than a month knows that this isn't currently the case. While this is of course the ultimate goal, and until then all web browsers clearly miss the mark, the truth about web-standards today is that they are standards because of the high level of standards they bring to your development.

By writing code that is web-standards compliant; you are ensuring your application to be compatible with the future and are saying that you want your application to be usable for another two, five, or even ten-years. Without the use of web standards, who knows how long the proprietary code you used will last? That's a tremendous risk that no company can ever take. Web standards provide a way to ensure that your applications will work ideally for the long haul. Not only that, they are also the best way to ensure they are the most powerful for the long haul. Proprietary features are the equivalent of get-rich-quick schemes in that while they provide you with the initially buzz that originally sold you on the product with the buzz soon dying off leaving you with a distaste for the temporary world you involved yourself in.

To wrap up, you can think of Ajax development as being verified, standards-based, event-driven, potentially object-oriented, JavaScript coded, asynchronous web development which brings the potential of desktop applications to the web. Before Ajax, online mail services were slow and bulky, but now with Ajax and its application in Gmail, we finally have an online e-mail service that is efficient and powerful to meet the today's needs. What about your application development? your websites? Wouldn't you like the public to say the same about your applications and websites? If so, then asynchronous development, JavaScript, XML, and web-standards all wrapped in this new world called Ajax are your new tools for success!