AJAX breathes new life into Web apps

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.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell Back to 'browser' report  DOWNLOAD PDF Click here to download InfoWorld's special report The browser reloaded

“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 example, 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,” 37signals’ 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.

Click for larger view.

Code headaches
Dealing with browser ambiguities is just the first challenge. Development tools for building JavaScript are still few and they 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-users 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 (see “Pushing AJAX Forward,” page 41).

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.