Ajax: Ready for the Web

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

I guess it finally has happened. We have run out ofTLAs–three-letter acronyms. You would think 17,576 uniquecombinations would be sufficient for techie buzz phrases butapparently 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 hasAjax for Dummies for sale (actually, advanced sale–it will not beavailable until February 2006). I have a spot reserved for it on mybookshelf right next to Mensa for Dummies. The book descriptiongushes, "Major Web players are already using Ajax to create a newgeneration of Web applications." Great. Is this similar to theKatie Couric effect (which is a bit like "if something is trendyenough to be mentioned on the Today show, it isn't trendyanymore")? Should we even be discussing a technology that has aDummies book in a column called "Trends & Tech"? Why not? Ajaxis an interesting amalgam of existing technologies and deserves alook.

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

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

A typical user experience on the Internet runs something likethis: User types in a URL, and the page is sent from the server tothe client Web browser. The user clicks on link X or button Y. Arequest is sent to the server, and an entire new page is returnedto the client and reloaded. Repeat ad infinitum. Page after page ofsynchronous requests and responses. Hey, we are talking HTML, andgiven it is a static markup language, there aren't a lot ofoptions–that is, there aren't a lot of options if we serve up onlyHTML. In fact, we have done
a lot of things to make Web pages more interesting and moredynamic–JavaScript, VBScript, IFrames, and Java virtualmachines.

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

The Heart of Ajax

So, let's see what makes Ajax tick. Traditional Web applicationscapture input or data from a user and post that form back to theserver where processing is accomplished and an entire new page isreturned to the client. An Ajax application is designed to processdata on the client side, if possible. If server-side processing isnecessary, only the data would be posted to the server and only theresults would be returned to the client. The entire page would notbe reloaded. Communication with the server would take placeasynchronously, so the user may not even be aware a server roundtrip is occurring. Let's take a very simple example.

A policyholder is changing her address. She types a new streetaddress into the "change" box and hits submit. That changeimmediately is reflected in the customer information displayedelsewhere on the page. Meanwhile, behind the scenes, the Webbrowser is using an XMLHttpRequest object to exchange data with theserver and update the database. The user may see her new databefore it even is changed in the database. How about updating ashopping cart? Changing a quantity or deleting a line item can makee-commerce painfully slow. Updating the relevant bits of a shoppingcart client side really could speed things up and result in fewabandoned carts.

This isn't new. We have been able to do similar things usingIFrames, various scripting languages, and ActiveX controls for sometime. What is new is more of a general overall approach to Webprogramming. The paradigm is this:

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

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

o If you need to refresh the page with information from theserver, refresh only that information that is changed–don't wastetime and bandwidth with more round trips than absolutelynecessary.

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

The Key Is JavaScript

JavaScript is the meat of the whole thing. JavaScript has beenaround in one form or another almost since about 1995–which makesit really old in dog years and even older in Internet years.JavaScript is an interpreted language supported by all modern Webbrowsers. As an interpreted language, it is not particularly fastor efficient, but with most client machines having more horsepowerthan they need, it really doesn't matter. Nor does a scriptedlanguage provide much security for your carefully crafted code. Youcan try to hide it all day, but if it is running on your box, youcan see the code. And that means I can steal it for my own coolAjax application.

Every Web browser (and other tools, such as Adobe Acrobat) hasits own JavaScript interpreter–and those interpreters may exposedifferent sets of methods and objects to the script. And thosemethods and objects interact with the browser's DOM, which may ormay not exactly match the W3C DOM standard. In fact, let's drop theeuphemisms–you can count on different behaviors from differentbrowsers from the same script. That means writing the Ajax "engine"that drives your nifty little Web app may be a little morechallenging than checking for "msie" or "opera" or "safari."Actually, that is what makes programming Ajax so much fun. Withouta real debugging environment, you can gain a lot of experience veryquickly 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 downso tight I can't get to my own Web sites. (I guess I gave myselfaway there–now you know what Web client I use.) We spend aninordinate amount of time on technical support calls talking peoplethrough the process of unlocking their browsers enough to use theWeb sites they have paid for. This has become a real problem. ManyWeb sites (such as my bank) specify Internet Explorer, but anout-of-the-box XP installation has so much security on IE that thebanking application won't work correctly. We have created asubculture of unsavvy computer users who are convinced cookies andclient-side scripting are part of the big plan to steal theiridentities–or at least spy on them.

Google's mail service, Gmail, is a well-known Web applicationthat uses Ajax technology as does its mapping service(http://maps.google.com). One of the really nice features of GoogleMaps is the ability to drag the map around and see it scroll inreal 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 desktopapplications that run in your Web browser.

The AjaxDifference

Using an Ajax-enabled application is a different experience froma typical Web application. Click on an e-mail in Gmail, and theprogress bar in your Web browser doesn't show a page loading–as faras your browser is concerned, the page is loaded. What does happenis a little red "loading" image appears in the upper-right-handcorner of the window while the XMLHttpRequest does its round tripand quickly renders the e-mail. Comparison with the sometimesagonizingly slow reloading of the entire page using other Webe-mail clients' Gmail is unfair. There is no comparison.

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