Opinion: This one-year-old label intensifies interest but obscures options and burdens.
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.
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" appone that responds dynamically to user actions, rather than waiting for an explicit "submit" command.
Note well the qualifier "can be."
Handheld devices, with their modest processor and memory resources, may disappoint users who first encounter AJAX responsiveness on much faster desktops and laptops.
Google and BlackBerry maker RIM have signed an agreement that will allow users to access Google Talk and Google Maps on the go. Click here to read more.
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.
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.
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 dataas opposed to conventional Web applications, whose content changes only when the user asks for that to happen.
Next page: AJAX faces cultural obstacles too.