One year ago, Thomas Lackner didn't ask much of JavaScript. When he sketched out the architecture to a Web application, he knew he could count on the browser language for "set-a-cookie hacks" and for loading images, but he turned to the server side for the heavy lifting. But when Google began launching highly interactive Web sites such as Gmail and Google Suggest, the scales dropped from Lackner's eyes and he saw the opportunity.

"It all clicked in my head the middle of 2004," Lackner says. "I started trying to add AJAX components to every Web app I worked on."

AJAX is the newly minted acronym encompassing a fresh vision of empowered browsers: Asynchronous JavaScript and XML. Before AJAX, Web pages displayed links, forms, and buttons. When a user clicked on a link or a button, the browser sent a message to a distant server asking what to display next. JavaScript would typically be used for nothing more than to check form inputs. Web pages were as static as pages in a book.

The post-AJAX browser can think on its own without saying "Mother may I?" to a distant server. Processing threads running in the background preloads page content. If a user clicks on a link or a button, the browser can update page content using JavaScript. Google's Gmail, for instance, hides or displays parts of an e-mail thread without waiting for a response from its server, eliminating network lag. If information must go to the server, it too is sent by a background process.

Brendan Eich, the creator of JavaScript at Netscape, says the world is just now discovering what he imagined back in 1995. He says, "We [Marc Andreessen and I] always intended JavaScript to enable client-centric apps that did not have to reload pages from a server."

A New Kind of App

AdaptivePath's Jesse James Garrett, who coined the AJAX acronym in an essay written in February, says that the response has been surprising. "Right now, it's all so new that what we've got is a lot of excitement," he says.

The excitement is understandable when you consider the advantages AJAX brings. For one thing, it greatly simplifies software distribution. Browsers load AJAX applications automatically. Customers are often reluctant to install custom applications, but most people can be convinced to visit a Web site.

The AJAX approach has several other advantages, as well. JavaScript running on the client reduces bandwidth and processing demands on the server. Well-designed code that is truly asynchronous also gives the server more time to respond to queries, reducing this load even further by spreading out peak demands. It even increases security by encrypting data on the client side, before it travels across the network.

The Basecamp project management application from 37signals is a good example of a Web application developed using the new paradigm. Adding a new to-do item pops open a window to accept input without a round-trip to the server. But when the new item is saved, the browser still must wait to ensure that it was stored successfully. JavaScript code updates the server in the background while displaying the note, "Moving...Just a moment." There is still plenty of interaction with the server, but the JavaScript code speeds it by handling many of a user's clicks.

David Heinemeier Hansson, a programmer at 37signals, says he's concentrating on removing the lag time when a user submits a form. "If you have a Weblog and you add a comment, it will be updated on the server side in the background. Whenever you need to add or change content, you can do it without reloading."

Some of the buzz around AJAX has been generated by Web designers as well as programmers. AJAX's flexibility is invigorating for Web designers because JavaScript can control any aspect of any images or type on a page. Fonts can grow or shrink. Tables can add or lose lines. Colors can change. Although none of these capabilities are new to programmers accustomed to building client applications -- or, for that matter, Java applets -- they are novelties to Web designers who would otherwise be forced to rely on Macromedia Flash.

The excitement may signal a newfound synergy between designers and programmers, who can now speak the same language about the page. Notations from CSS, a language spoken by Web designers, are used directly by the JavaScript coders. The result is a Web page that behaves with some of the snappiness of a dedicated client application -- without any of the headaches of distributing and installing software on a client machine.

"For me, it's not about building something big, it's about making sure that the experience is right for the right people," says Jason Fried, president of 37signals.

Browser Problems Persist

Enthusiasm for these new techniques, however, is usually tempered by reality. There are few good tools for AJAX development, the platform can be unstable, and adherence to standards is inconsistent. Even the biggest proponents complain about differences between Web browsers and concede that they don't understand the best way to add many interactive features. What's more, these new capabilities can confuse users who don't expect the features and, in some cases, can even open up new security gaps.

Many AJAX applications require features that are only included in the version of JavaScript bundled with newer browsers such as Firefox or IE 5.5. Others use functions that work correctly in one version of a browser but not another. The XMLHttpRequest object, for instance, parses XML from Web services directly, a feature that makes it much easier for a programmer to interact with any source of XML. Before this feature debuted in IE 5.0, developers could still download information from distant Web sites, but they needed to use different frames.

Some of the newest browsers offer stable platforms for using XSLT (XSL Transformation), but the details seem to be fluid. There are big differences in the way IE 5.0, 5.5, and 6.0 handled namespaces. Mozilla 1.8 now shares many of the same capabilities, but earlier versions don't.

Programmers are forced to smooth over some of these ambiguities by building custom loaders that match the code to the browser version. Rob Brown, an early AJAX developer and creator of the Firefox plug-in Aardvark, is optimistic. "Luckily, most browser differences can be fairly easily encapsulated into a few utility functions, and the 'meat' of your AJAX application can be free from ugly conditional code," he says.

But these contortions can be painful, and some are simply abandoning earlier browsers. "We're working on a project now called Backpack and it's going to be one of the most advanced AJAX apps outside of Gmail," Fried says. "We made the decision to just say no to IE 5. It was a conscious decision we made. It's about time."

This same challenge faces many enterprise designers. If a Web application will only be used internally, an enterprise architect can reasonably assume that every browser in the company meets a certain specification. Such a uniform infrastructure is much easier for programmers. But a company that distributes Web applications to customers can't make the same assumptions. There will always be some customers running old versions of browsers.

Code Headaches

Dealing with browser ambiguities is just the first challenge. Development tools for building JavaScript are still few and often have a rough feel to them. Features that programmers of other languages take for granted are just now appearing in the JavaScript world -- for example, debuggers such as Mozilla's Venkman aren't widely used by JavaScript coders accustomed to reloading pages to look for errors.

Ed Felten, a professor of computer science at Princeton University, cautions that programmers may inadvertently insert security holes when translating server-side features into JavaScript code. Although JavaScript runs incoming code in a "sandbox" with no API for accessing local files, opportunities for mayhem remain because the code can still access external Web sites. DDoS attacks, for instance, can be easy to code.

What's more, JavaScript code is not compiled the way languages such as C and Java are. And end-user can view or even edit the JavaScript code before it runs. For example, an attacker could search for strings of text containing SQL instructions and replace that code with different queries that retrieve different information from the server. "Every time a string goes anywhere, you have to think about it," Felten says.

The appearance of new glitches such as these requires Web designers to think twice about new features. Browser users have come to understand the way traditional Web applications work. They have been warned many times, for example, that clicking a button twice could create a double charge on their credit card. AJAX applications break many of those assumptions.

"People are used to clicking a check box and confirming things. Now you don't have to. That introduces some confusion," 37signals' Fried explains. "Now in some places there's a button and in some places there isn't. There are a lot of pitfalls, but they're not insurmountable by any means."

What's more, the JavaScript language itself is still evolving. Whereas languages such as Java and C++ are highly standardized and governed by relatively rigorous committees, JavaScript still feels like an experiment at times. There are huge differences between the way that IE, Mozilla, and Safari execute some JavaScript code and often substantial differences between different editions of the browser. The core of the language is a standard known officially as ECMAScript, but each browser often handles other features differently.

Will AJAX Prevail?

Despite the cross-platform challenges -- and some developers point out that there is little reason for Microsoft to make its browser completely compatible with Firefox or Opera -- this new model shows promise. AJAX applications can have much if not all of the functionality of client-side applications. Many programmers react with surprise when they see editors such as Bitflux, FckEditor, or Kupu written entirely in JavaScript, but applications such as these are likely to become commonplace, and even more features are bound to emerge.

Some companies see an opportunity here. Thomas Lackner's development group at ModernMethod is rolling some of its development efforts into an open source library Lackner calls SAJAX, short for Simple AJAX. JackBe, on the other hand, sells a collection of small libraries that abstract away many browser incompatibilities. A programmer can add Excel-like spreadsheets or forms to a Web page and the JackBe libraries will handle much of the interaction with the client.

Which brings us back to the future as the Web finally discovers what Eich and the original team at Netscape imagined long ago. When asked what held it back, Eich speculates, "It was hampered by incompleteness, a rush to standardize, the browser wars killing Netscape, and a dependence on Java to do 'real graphics' and 'real network input/output.'" Now that JavaScript has matured beyond those problems, Eich is enthusiastic to see what comes next.

What's next after AJAX

The rapid spread of the term AJAX (Asynchronous JavaScript and XML) -- from Weblog to Wall Street Journal within weeks! -- might lead developers to assume it's a breakthrough that heralds the death of desktop applications. There's certainly a kernel of truth in that: The recent spate of new Web applications under the AJAX banner have redefined end-users' expectation of what's even possible within a Web browser by offering smooth scrolling, incremental updates, and more responsive input forms (see " AJAX breathes new life into Web apps").

Nevertheless, so-called fat-client UIs still retain one fundamental advantage over Web UIs: real-time event notification. AJAX alone does not address IM, stock tickers, and other collaborative applications that require "push" data streaming.

The key goal of AJAX-style applications is to decompose jarring transitions that download an entire new Web page into a series of smaller, more frequent transactions. Developers consider AJAX to be "asynchronous" because data can be updated without interrupting the user. For example, Google Maps dramatically reduces the perceived latency of scrolling a map by only downloading the newly visible tiles and moving the rest.

In the middleware community, however, the formal definition of asynchrony refers to the ability to send a message at any time, in either direction. AJAX provides the upstream direction, but HTTP would appear to make server-initiated transmission impossible.

Fortunately, clever developers have exploited a loophole in HTML to address this. Browsers are designed to display pages incrementally while downloading pages from slow Web sites. Using hidden frames and JavaScript tags, HTTP can be (ab)used to hold open a long-lived response connection, allowing an application to stream data into the browser.

The simplest way to exploit this is to turn the browser into a 21st-century "green screen" dumb terminal. Manuel Kiessling's open-source ARSC (A Really Simple Chat) uses AJAX techniques to send input lines upstream, whereas a modified HTTP server that holds open thousands of simultaneous connections rebroadcasts the chat stream to other users. Another example is KnowNow's SpeedReader product, which is useful for alerting employees to relevant RSS news items.

The subtler and broader implication of combining AJAX with asynchronous event notification is to extend publish-and-subscribe application integration across the Internet. Several open-source platforms provide powerful abstractions for connecting fully interactive Web UIs to enterprise applications and Web services. Nevow (nee Woven LivePage) and Pushlets extend the event loop familiar from model-view-controller GUIs for Python and Java, respectively. Mod_PubSub is designed as an event bus that uses URL path names as topics to implicitly invoke programs written in a wide range of languages. Commercially, KnowNow's LiveServer provides enterprise-class scalability (and even connects to and from Microsoft Excel spreadsheets).

The clear benefits of migrating desktop applications to the Web in terms of maintenance, security, and scalability must be weighed against the costs of slower response times, limited interactivity, and less-than-beautiful graphical interfaces. With AJAX, push technology, and the ubiquitous plug-ins for PDF and Flash, the Web is closer than ever to becoming a viable default platform for application development.