Click, pause, view. Click, pause, view. The Web experience we've known for years--something grabs our attention, we click on it, wait a second, then get a new page--is sequential and staccato compared with the seamless interactivity of parts of Amazon.com, Google, and Yahoo, where new software development approaches make applications flow and graphics pop. But business Web sites don't have to be boring, and site developers are increasingly mimicking the megaportals. Ajax is how they're doing it.

The Web programming approach--JavaScript logic acting on Dynamic HTML within a browser window--supports interactive elements and breaks the cycle of laborious page downloads. Instead of a single interaction per page, where the user clicks on a link to bring up information or another Web page, Ajax allows a page to conduct many exchanges of data between user and Internet server.

(click image for larger view)

It changes the performance of Web apps from a series of minidownloads and momentary delays to instantaneous data delivery. At Netflix, when a user mouses over the title of a film, the site immediately responds with the movie's actors and story line. That's Ajax at work. At American Airlines, a manager builds the next day's schedule by scrolling across a grid that spans 100,000 flights, an impossibly large display for a single HTML page. That capability is made possible by OpenRico, an Ajax toolkit created by Sabre Holdings. And when Google users painlessly share data that populates their Google Calendars, Ajax makes it happen.

The Ajax approach requires the activation of components in the browser window, usually after a download from an Internet server. They frequently remain in the browser's cache for activation without repeated downloads, speeding Ajax applications after the initial download. Depending on their number and richness, what components can accomplish in the browser window may be a little or a lot. Ajax essentially gives some control over the "weight" of a Web client--from light to a little heavier--back to application developers. In the world of HTML pages, the client is the browser window, as thin and passive as a mainframe terminal.

Businesses are starting to show more interest in Ajax's ability to generate fast, useful, and sticky Web sites. But Ajax adoption is happening gradually--there's no stampede to use it. There are reasons business technology managers are taking their time.

Trouble With Tools

The Ajax scene has been chaotic, filled with low-level toolkits, donated open source tools, and higher-level--often proprietary--Ajax frameworks. Only seven months ago, few Ajax toolkits were available, but now there are more than 70, says Rod Smith, IBM's VP of emerging technologies and an Ajax backer. A market shakeout over the next two years eventually will reduce that number to a handful of survivors, Smith predicts. In the meantime, IBM is supporting OpenAjax, an initiative that defines common actions for toolkits to implement, and the company has moved a few toolkits into the Eclipse open source programmer's workbench.

Businesses that don't want to wait for a shakeout face a choice: Do they pick an Ajax toolkit that solves their specific problems, but which might be too specialized for longevity? Or try to guess which has the legs to still be around in a few years? For that matter, should they choose a toolkit at all? It's possible to develop directly with Ajax's underlying technologies, JavaScript and Dynamic HTML, seasoned with the Cascading Style Sheets standard that applies a predetermined style to a page. That way, enterprise developers learn basic skills while avoiding the inevitable toolkit obsolescence.

Another option is to pick one of the more sophisticated Ajax development frameworks that hide underlying complexities, such as those from Backbase, BEA Systems, Bindows, Exadel, and Tibco.

Only a few companies will develop an army of internal Ajax developers, the way Amazon, Google, and Yahoo have. Most IT departments have application development skills like Microsoft .Net, C#, standard C++, or Java. But programmers with these skills usually don't know JavaScript, which isn't object-oriented. That means most of the approaches they've worked with over the last 10 years don't apply.