Ajax: Ready for the Web

Like the ancient Greek who shared its name, an Ajax application can be a hero–but now in the fight against Web site mediocrity.

I guess it finally has happened. We have run out of TLAs–three-letter acronyms. You would think 17,576 unique combinations would be sufficient for techie buzz phrases but apparently not. The latest and greatest TLA is, in fact, an FLA (four-letter acronym). How do I know it is the latest and greatest? Because it already has a "Dummies" book devoted to it. Amazon has Ajax for Dummies for sale (actually, advanced sale–it will not be available until February 2006). I have a spot reserved for it on my bookshelf right next to Mensa for Dummies. The book description gushes, "Major Web players are already using Ajax to create a new generation of Web applications." Great. Is this similar to the Katie Couric effect (which is a bit like "if something is trendy enough to be mentioned on the Today show, it isn't trendy anymore")? Should we even be discussing a technology that has a Dummies book in a column called "Trends & Tech"? Why not? Ajax is an interesting amalgam of existing technologies and deserves a look.

According to Homer, Ajax was a large, rather dim-witted fellow but a heck of a warrior. He made a real name for himself during the Trojan War. Jesse James Garrett defines Ajax as shorthand for Asynchronous JavaScript + XML. I mention Garrett because he is responsible for kick starting the interest in Ajax with his February 2005 essay, "Ajax: A New Approach to Web Applications" (see http://www.adaptivepath.com/ publications/essays/archives/000385.php). He is a founder of Adaptive Path, a user-experience consulting, research, and training firm.

The concepts evoked in Garrett's essay are not groundbreaking or astonishing, but they do reflect a good common-sense approach to Web computing and provide a pathway that steps around some of the common stumbling blocks we find in Web applications.

A typical user experience on the Internet runs something like this: User types in a URL, and the page is sent from the server to the client Web browser. The user clicks on link X or button Y. A request is sent to the server, and an entire new page is returned to the client and reloaded. Repeat ad infinitum. Page after page of synchronous requests and responses. Hey, we are talking HTML, and given it is a static markup language, there aren't a lot of options–that is, there aren't a lot of options if we serve up only HTML. In fact, we have done
a lot of things to make Web pages more interesting and more dynamic–JavaScript, VBScript, IFrames, and Java virtual machines.

Java virtual machines were supposed to turn every Web browser into a little client-server application framework. The idea was every operating system and then every Web browser would have a Java virtual machine that would have a common API so you could write Java Web applications that would be machine and platform portable. Right. There was a good idea that went bad. I used to support a Web publishing application that used the Java VM to generate the table of contents and indexed searching. It worked cross platform and cross browser for about a month. Then the browser wars heated up, and we continually had to keep throwing on new patches to keep this thing running. Next, we entered into the Java virtual machine legal wars, and the Microsoft-supported VM disappeared and was replaced with the "legal" Sun VM, which broke everything. I suppose there is a lesson to be learned there.

The Heart of Ajax

So, let's see what makes Ajax tick. Traditional Web applications capture input or data from a user and post that form back to the server where processing is accomplished and an entire new page is returned to the client. An Ajax application is designed to process data on the client side, if possible. If server-side processing is necessary, only the data would be posted to the server and only the results would be returned to the client. The entire page would not be reloaded. Communication with the server would take place asynchronously, so the user may not even be aware a server round trip is occurring. Let's take a very simple example.

A policyholder is changing her address. She types a new street address into the "change" box and hits submit. That change immediately is reflected in the customer information displayed elsewhere on the page. Meanwhile, behind the scenes, the Web browser is using an XMLHttpRequest object to exchange data with the server and update the database. The user may see her new data before it even is changed in the database. How about updating a shopping cart? Changing a quantity or deleting a line item can make e-commerce painfully slow. Updating the relevant bits of a shopping cart client side really could speed things up and result in few abandoned carts.

This isn't new. We have been able to do similar things using IFrames, various scripting languages, and ActiveX controls for some time. What is new is more of a general overall approach to Web programming. The paradigm is this:

o If you can accomplish some processing on the client side, do it–make your Web application act like a client-side application.

o If you need to exchange data with the server, do it behind the scenes, that is, asynchronously, so the user is not waiting for something to happen.

o If you need to refresh the page with information from the server, refresh only that information that is changed–don't waste time and bandwidth with more round trips than absolutely necessary.

All of this is accomplished using existing technologies, specifically, XHTML, CSS, the DOM, XML, XMLHttpRequest, and JavaScript–all technologies that should operate cross platform and cross browser. And what are all these acronymic items? XHTML–eXtensible HyperText Markup Language–is a cross between XML and HTML. Redefine HTML as a subset of XML rather than SGML. CSS–Cascading Style Sheets–are elements of a Web site that define formatting for structural elements of documents such as XML (or HTML or DHTML). The DOM–Document Object Model–is a W3C programming interface specification (http://www.w3.org/DOM/) that allows programs (scripts) to modify the content, structure, and style of Web documents. I refuse to define XML (again), and XMLHttpRequest is a set of APIs that can be used by any Web-browser scripting language to transfer XML (or other data) to and from a Web server.

The Key Is JavaScript

JavaScript is the meat of the whole thing. JavaScript has been around in one form or another almost since about 1995–which makes it really old in dog years and even older in Internet years. JavaScript is an interpreted language supported by all modern Web browsers. As an interpreted language, it is not particularly fast or efficient, but with most client machines having more horsepower than they need, it really doesn't matter. Nor does a scripted language provide much security for your carefully crafted code. You can try to hide it all day, but if it is running on your box, you can see the code. And that means I can steal it for my own cool Ajax application.

Every Web browser (and other tools, such as Adobe Acrobat) has its own JavaScript interpreter–and those interpreters may expose different sets of methods and objects to the script. And those methods and objects interact with the browser's DOM, which may or may not exactly match the W3C DOM standard. In fact, let's drop the euphemisms–you can count on different behaviors from different browsers from the same script. That means writing the Ajax "engine" that drives your nifty little Web app may be a little more challenging than checking for "msie" or "opera" or "safari." Actually, that is what makes programming Ajax so much fun. Without a real debugging environment, you can gain a lot of experience very quickly figuring out what works for what browser!

I spoke earlier about code security. How about browser security? Every time I apply a service pack, my Web browser gets locked down so tight I can't get to my own Web sites. (I guess I gave myself away there–now you know what Web client I use.) We spend an inordinate amount of time on technical support calls talking people through the process of unlocking their browsers enough to use the Web sites they have paid for. This has become a real problem. Many Web sites (such as my bank) specify Internet Explorer, but an out-of-the-box XP installation has so much security on IE that the banking application won't work correctly. We have created a subculture of unsavvy computer users who are convinced cookies and client-side scripting are part of the big plan to steal their identities–or at least spy on them.

Google's mail service, Gmail, is a well-known Web application that uses Ajax technology as does its mapping service (http://maps.google.com). One of the really nice features of Google Maps is the ability to drag the map around and see it scroll in real time or zoom in real time. How is it done? Ajax, my friend. Turn off script support in your browser, and try to drag that map. It can't be done. The "nonscripted" versions–read: "non-Ajax" versions–of Gmail and Google Maps are slow, synchronous, traditional Web apps. The Ajax versions are fun-to-use desktop applications that run in your Web browser.

The Ajax Difference

Using an Ajax-enabled application is a different experience from a typical Web application. Click on an e-mail in Gmail, and the progress bar in your Web browser doesn't show a page loading–as far as your browser is concerned, the page is loaded. What does happen is a little red "loading" image appears in the upper-right-hand corner of the window while the XMLHttpRequest does its round trip and quickly renders the e-mail. Comparison with the sometimes agonizingly slow reloading of the entire page using other Web e-mail clients' Gmail is unfair. There is no comparison.

Ajax is one of those technology shifts that make you want to smack your head and say "Duh." IFrames and scripting have been around for a while. We have had the ability to create Web applications that act more like a desktop application for a long time. Why do we all have to be prodded into applying this type of technology to our Web applications? Probably because it didn't seem like such a big deal. Most Web applications are fast enough, probably because most of us remember dial-up. Most Web applications are efficient enough. But that doesn't make them as good as they could be. Why settle for mediocrity? Spend a few minutes examining this technology. I'll bet you will want to incorporate it into your next Web project.

Special Reports /

Ajax: Ready for the Web

Related Stories

Recommended For You