eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Its almost time to send first-birthday-party invitations for AJAX, a catchy label (though not a novel idea) that has quickly become the banner buzzword of standards-based interactive applications for the Web. The benefits of AJAX are far more obvious than its burdens on developers, and eWEEK Labs therefore offers this perspective on the choices that developers face.
The term AJAX has its origins in “Asynchronous JavaScript and XML.” The first word in that spellout is the most important, while the others should not be taken too literally.
An AJAX application combines behind-the-scenes server interactions with client-side user interface rendering. “The user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something,” said Jesse James Garrett, co-founder of San Francisco-based Web consultancy Adaptive Path LLC., in his widely cited article propounding the AJAX label.
The result, as clearly apparent in AJAX applications such as Google Inc.s Google Maps, can be a Web application that looks and behaves much more like a conventional “thick client” app—one that responds dynamically to user actions, rather than waiting for an explicit “submit” command.
Note well the qualifier “can be.”
Even Garrett has stressed that the promise of AJAX is a potential rather than intrinsic improvement in the users Web experience. “AJAX applications inevitably involve running complex JavaScript code on the client. Making that complex code efficient and bug-free is not a task to be taken lightly,” Garrett warned in his AJAX essay.
Developers should also consider the performance implications: As bandwidth stops being the limiting factor, eWEEK Labs is already seeing rich AJAX applications that expose processor speed and JavaScript implementation issues as new bottlenecks to Web site interaction.
Handheld devices, with their modest processor and memory resources, may disappoint users who first encounter AJAX responsiveness on much faster desktops and laptops.
Advocates of standards-based development have noted the unfortunate history of JavaScript, the “J” in AJAX. “In the past, browsers made a distinct point of being as incompatible as possible, and they gleefully ignored standards such as W3C [World Wide Web Consortium] recommendations,” states the JavaScript Manifesto of the DOM Scripting Task Force of the Web Standards Project. Experience at eWEEK Labs confirms continued browser-specific variation in AJAX application behaviors, including both display and printing.
It requires a real effort for developers to skirt the browser-war debris that clutters the AJAX battlefield, as noted by Brett McLaughlin of OReilly Media Inc. in a December tutorial published on IBMs DeveloperWorks site. The defining act of an AJAX application is the creation of a JavaScript XMLHttpRequest object, whose interfaces enable behind-the-scenes communication with the server. Different browsers create that object using different incantations. McLaughlin urges developers to encapsulate the differences in JavaScript exception-handling mechanisms, coming up for air with their chosen variable name bound to a proper XMLHttpRequest object in any AJAX-capable browser.
Once the asynchronous engine is started, the challenge for developers is to make an AJAX application better than a Web 1.0 ancestor without being jarringly different. For example, Web users are accustomed to the idea that if they dont like what theyve just done, the browsers Back button will get them to a previous state from which they can try something else. An AJAX application should not deprive the user of this same sense of security. Web application developers must therefore implement “undo” to a degree that was not previously their problem.
Web users also expect to be able to copy a URL and send it to another user, who will then be able to navigate directly to the same page in the same state. AJAX applications must make explicit provisions for this, generating and displaying a state-representing URL on request and interpreting that URL correctly when it is received.
Connection management issues that were previously the problem of browser designers may require an AJAX application to provide specific JavaScript logic—especially if an application offers multiple tabbed panes or other user interface elements whose updates should proceed in parallel but with priority given to what the user is currently seeing.
AJAX updating of Web-page elements can be too seamless if a user doesnt even notice that something has changed. This requires AJAX application designers to consider various means (such as temporary color highlights or animations) for briefly calling attention to new data—as opposed to conventional Web applications, whose content changes only when the user asks for that to happen.
Next page: AJAX faces cultural obstacles too.
AJAX faces cultural obstacles
too”>
Other barriers to AJAX development are as much cultural as technical. The perception that real programmers write [insert technology here] applications, with the insertion being chosen from .Net, Java or other technology du jour, may be entrenched in a development shop.
Developers may even argue that the generation beyond AJAX is already being defined by Microsoft Corp.s .Net languages and frameworks—specifically, the presentation and communication foundations of Microsofts forthcoming Windows Vista. This platform offers developers the prospect of powerful asynchronous communication mechanisms plus engaging client-side interaction, freed from the confines of a Web browser. One could argue that AJAX takes aim at the problems of browser-based application development, just as the developer community prepares to leave the browser behind.
If a preference for open standards drives AJAX adoption nonetheless, an outcome to be avoided is one in which AJAX is oversold. Its appeal may seduce newly empowered front-end developers into shifting too much of a task off the server and into the browser. “Front end technology can never replace … back end technology, or vice versa, because the two have different purposes,” states the JavaScript Manifesto. “Back end technologies search for, collate, and serve data and business logic. Front end technologies present this information to the user. The two need to be properly separated.”
AJAXs “X” for XML should be taken as descriptive, not prescriptive. “XML is the most fully developed means of getting data in and out of an AJAX client, but theres no reason you couldnt accomplish the same effects using a technology such as JavaScript Object Notation or any similar means of structuring data for interchange,” Garrett said. He apparently couldnt resist, however, the temptation to embed a reference to XML as the price of a catchy name.
Developers must steel themselves against the implication that theres some organic connection between JavaScript and XML that makes AJAX an all-or-nothing proposition. Its useful for developers to appreciate the generality of the ideas that are at risk of becoming straitjacketed by the AJAX label. “The name AJAX was apparently coined because HTTP + XML + HTML + XMLHttpRequest + JavaScript + CSS was too long,” suggested software researcher Ian Hickson in a blog posting one month after the AJAX name emerged.
Understanding each of those component technologies, and letting each do what it does best, may be a better approach than seeking out a packaged AJAX solution and letting its choices and limits become the developers as well. Microsoft Program Manager Dare Obasanjo made this point from another perspective with a comment on his blog last March: “What I find particularly disappointing about the AJAX hype is that it has little to do with the technology and more to do with the quality of developers building apps at Google [Inc]. If Google builds their next UI without the use of XML but only JavaScript and HTML, will we be inundated with hype about the new JUDO approach (Javascript and Unspecified DOM methods) because it uses proprietary DOM extensions not in the W3C standard?”
Googles high profile has contributed to an aura of fairy dust surrounding AJAX, making it seem both more powerful and less risky than it may prove to be in the hands of any but the most talented developers. But as Sophocles wrote in 440 B.C., “Ever do I behold thee scheming to snatch some vantage oer thy foes. Skilled in the chase thou seemest. Say what eager quest is thine, that I who know may give thee light.” Thats Athenas opening speech in the classic play “Ajax.”
Peter Coffee can be reached at peter_coffee@ziffdavis.com.