AJAX changes everything, believe it

AjaxificationThere are a few things you need to know about Asynchronous JavaScript and XML, one of the most talked about trends in Web app dev. First, AJAX isn’t strictly a technology but just one way to solve a fairly common set of problems. Second, codejockeys are divided over AJAX. It’s not that they don’t think it’s a viable approach for building highly interactive Web apps. Most of them do.

But to some programmers, AJAX smacks of marketing and pre-fabricated hype. After all, smart developers were using AJAX-like approaches long before AJAX was first popularized. It wasn’t until February 2005 when Adaptive Path consultant Jesse James Garrett used “AJAX” to describe a model for building rich client apps using JavaScript and XMLHttpRequest that next-gen Web app dev really took off.

The Big Idea

  • Adaptive Path consultant Jesse James Garrett used “AJAX” in February 2005 to describe a model for building rich client apps using JavaScript and XMLHttpRequest.
  • Today, AJAX is used primarily for flashy interfaces and features that enrich user experiences on client-side apps.
  • The AJAX ecosystem is still evolving, so standardization and security are concerns.

As far as many programming stalwarts are concerned, it shouldn’t take an acronym to sell a truly compelling app dev vision. “I should make it clear from the start that I don’t use AJAX, as it’s called in trendy circles,” says one freelance codejockey, who asked not to be named. “I do work for a couple of companies that use XML over HTTP, and have been doing so for several years—since 1999 in one case.”

Excited about AJAX apps
Yes, AJAX as a technology model isn’t exactly new. In the same sense, however, the identification and popularization of AJAX has been a revolutionary process because it happened quickly. In less than a year, it has become a buzzword and all but abrogated developer mindshare. More than that, however, AJAX’s success has forced the great mass of programmers—and their bosses—to finally come to terms with the most salient shortcomings of the conventional Web app dev model. What’s different about AJAX is not that it’s innovative, but that it’s disruptive. It also stimulates the imagination.

In this respect, AJAX excites codejockeys like Curt Hibbs, a senior software engineer with a global aerospace company. Although the pace of change at Hibbs’ company, which has more than 160,000 employees, is nothing less than glacial, it doesn’t matter, Hibbs says: He’s already sold on the AJAX vision. Up to this point, he explains, the slow pace of change has limited the appeal of Web apps in his org and elsewhere. But AJAX promises to change that.

“The use of AJAX techniques has both invigorated existing Web applications, and extended the range of what applications can be considered for Web deployment,” Hibbs argues.

Sweeter user experiences
AJAX was made-to-order for an outfit like Alliance Reservations Network, a Web-based aggregator of discount hotel rooms.

“We are using AJAX to help our end users find the exact city or airport they want to book from,” says Alec Whittington, a senior software engineer with Alliance. “In our old process, the consumer would type in the city they were looking for and we would then search our database. Often times, we would need to display another screen, [so they could] select the right city.”

Using AJAX, Alliance is able to allow consumers to narrow searches on the fly by displaying results as they type. “This presents the consumer with a richer user experience and less hassle,” Whittington explains.

To some extent, he acknowledges, Alliance could have accomplished the same thing using Java applets. But Java applets are kludgier than AJAX, and they’re more difficult to incorporate into Web apps, particularly when a variety of different browsers and display environments must be taken into account.

“I have never been a fan of Java applets because I feel they are very limiting for the end user and tend to take too much time just to initialize and load,” Whittington says. “AJAX is a generic way to do dynamic content without postbacks that can be done on any platform.”

The unlikeliest AJAX pioneer

Just because Microsoft and most J2EE enthusiasts don’t see eye-to-eye doesn’t mean Redmond hasn’t played a foundational role in the AJAXification of enterprise apps. Microsoft more or less invented the model on which AJAX itself is premised—the idea of asynchronous communication with an HTTP server, without first reloading HTML.

Microsoft first introduced the XMLHttpRequest technology that today enables the asynchronous magic of AJAX. Microsoft’s seminal spin on this idea—which it dubbed Remote Scripting—debuted in the Internet Explorer 5.0 time frame. Some Win32 programmers embraced it because it brought a new degree of dynamism to otherwise static HTML apps. Security advocates and Microsoft critics warned of the potential for disaster because malicious attackers could exploit cross-site scripting and other attacks to wreak havoc on Web clients and servers. Today, of course, the same transport mechanism that powered Remote Scripting—XMLHttpRequest—is at the heart of AJAX development.

These days, Microsoft is touting an AJAX-like vision of its own, called Atlas, which it’s yoked to its ASP .NET platform. Atlas isn’t yet officially available, but—if the technology preview is any indication—it’s going to offer an essential reduplication of the AJAX vision garbed in ASP .NET. At this point, Atlas will consist of several pieces: a client script framework to enable rapid construction of AJAX-like apps with rich UI functionality; ASP .NET Server Controls for asynchronous callback, among other features; an ASP .NET Web services integration component; a set of ASP .NET Building Block Services designed to reduce or eliminate coding for common tasks, such as adding or managing users; and a proposed set of Client Building Block Services.

While Atlas, in classic Microsoft style, offers a quasi-proprietary spin on the AJAX vision, .NET programmers have a host of third-party alternatives from which to choose, too. According to freelance programmer and blogger Michael Mahemoff, there are five AJAX frameworks for ASP .NET: MonoRail, WebORB, Ajax.NET, ComfortASP.NET and AjaxAspects. Pick your poison and start XMLHttpRequest-ing. But don’t peremptorily count Microsoft or .NET codejockeys out of the AJAX application stakes.

Stephen Swoyer

Whittington and Alliance aren’t alone in eschewing Java applets. As popular as Java and J2EE are, a lot of Web app developers just don’t like working with applets. For them, AJAX is sort of a godsend.

It’s not a Web dev panacea
“Java applets can’t compare with browser rendering capabilities,” says AJAX enthusiast Pavel Simakov, architect and head of development with 3Genius, an interactive media outfit. “The amount of work and skills you have to put into making Java look good is one-hundred-fold above what you need to do in HTML. Browsers do a superior job of dynamic re-layout and re-rendering of that Web page.”

Simakov, who has 20 years of experience as a commercial software developer, is using AJAX to help power 3Genius’ still-gestating online gaming and targeted advertising services.

Although he’s cool to the idea of AJAX as a Web app dev panacea, Simakov does cast it as a potentially revolutionary model. Far more than static HTML coding, he argues, AJAX dev has the potential to encourage more conscientious software design—premised on the model-view-controller paradigm favored by many OO enthusiasts.

The debate over XML and JSON

AJAX critics get most worked up over the X in XML. No, no, no, they seethe, a language as garrulous as XML isn’t an appropriate transport for even moderately-sized chunks of data—to say nothing of extremely large data sets.

They tout JavaScript Object Notation as a more robust alternative. JSON, by all accounts, is easier to work with than XML. It can be quickly parsed in JavaScript on the client using the eval() procedure. This is just one of the things JSON has going for it, according to blogger Michael Schwartz, the AJAX.NET mastermind. “If you have a look inside the AJAX.NET library, you can see that I’m not using XML to transfer the data to or from the server. I am using the JSON syntax because it is supported by, I think, all modern browsers including Pocket IE,” Schwarz writes. “It is very simple and you can get a real JavaScript object using one command: eval.”

Proponents say simplicity of this kind translates into superior performance, at least relative to XML. But JSON has another selling point: it’s a lot less garrulous than XML. Implemented correctly, this means better app performance and a snappier overall end-user experience, especially for apps that work with large data sets. JSON is also easier on the eyes than XML, which makes it easier to debug.

Despite the accolades, there’s no shortage of JSON skeptics. Programmer Dave Johnson, cofounder of eBusiness Applications, an AJAX software dev consultancy based in Vancouver, claims to have debunked JSON’s key selling point: transport brevity. Johnson argues that for some apps, XML is a more efficient carrier than JSON. Take, for example, data grids, where developers can accelerate an activity like data sorting by opting for XML and XSLT (Extensible Stylesheet Language Transformations) over JSON.

Johnson claims he ran a sorting benchmark in which he eval-ed JSON and XSLT-ed XML; the latter was faster in Internet Explorer, and the performance delta actually grew in proportion to the amount of data— number of rows—being sorted. JSON, on the other hand, was the better performer in the Firefox browser.

JSON skeptics don’t stop there, either. They claim pervasive use of JSON’s client-side eval() command— which, owing to the comparative paucity of serverside JSON parsers, is a given in most AJAJ app dev efforts—actually poses an unacceptable security risk. It’s conceivable, JSON skeptics say an attacker could exploit eval() to perpetrate a cross-site scripting attack against a large number of clients. In fact, it may already have been done.

On the other hand, secure JSON parsers have been developed for just this purpose. So developers can conceivably opt for the parsing method that’s most suitable for their requirements.

Alec Whittington, a senior software developer with Alliance Reservations Network, an aggregator of discount hotel rooms, says: “We make it a point to never pass sensitive data across an AJAX request. This precludes us from using it when the user is actually booking the reservation. I am sure that in the future as AJAX is more widely accepted, these limitations will dwindle.”

Many AJAX practitioners seem to feel there are benefits to both approaches. “JSON can sometimes be more lightweight than XML, and it is generally easier to read and write for humans,” says Chad Humphries, a senior software developer with a software development firm based in the Midwest. “In the end, the choice of JSON or XML isn’t really that important, as both sides of the request can parse both. It is more of a matter of preference,” Humphries asserts. “However, if you have to interoperate with a wide variety of systems you may find XML better suited, because so many systems are already natively XML for Web services and the like.”

Stephen Swoyer

The past is ugly as hell
“I look at AJAX to avoid page refreshes and add interactivity to sites,” he explains. “It’s nice to be able to update only part of the page without the user clicking [to refresh it]. But this is only part of the benefit. Another thing AJAX encourages is a model-view- controller design style for Web pages. In the past, with JSP/ASP/PHP scripts, pages are rendered server side, with lots of those scripts looking ugly as hell–no proper encapsulation or componentizing. With AJAX, one now has to really model data and [separate] it from stages of the page’s [lifecycle]: HTML page loading, AJAX data fetch and page update with XML data.”

Simakov sees a future in which tasks like Web app maintenance, redesign and refactoring are vastly simplified, thanks to MVC design principles and AJAX concepts and methods. “MVC allows one to handle frequent user interface changes without restarting the server,” he notes. “With AJAX, you can keep your server stable and generating stable XML data islands, handling day-to-day changes in the Web site in HTML, CSS, and JavaScript. Those things are easier to change and update compared to [recompiling the] server.”

That’s the long view. Right now, most AJAX app dev efforts are a lot less ambitious—in spite of the much-hyped triumphs of Gmail, Google Maps, and other highly interactive AJAX showcases.

Simple AJAX is better
“AJAX is a useful tool in Web development regardless of the primary language you work in,” says Chad Humphries, a senior software developer with a software development firm based in the Midwest. “However, it is just a tool to use when necessary. I have made use of AJAX in situations where clients needed a more responsive UI that supported reloading only partial parts of pages.”

Humphries—who’s a devotee of the Castle Project’s Monorail AJAX framework—says simple is often better when it comes to AJAX.

“One of the initial demonstrations provided commonly for AJAX, the auto complete dropdown list, has proven to be one of the most consistently useful to users,” Humphries says. “AJAX is a better solution to this type of interactivity than plug-ins or iframes, because it is built upon a technology that has been around for a while, and is standardized across most browsers without a plug-in.”

That’s a perspective endorsed by Scott Cate, president of, a developer of knowledgebase software. “AJAX for is all about the user interface enhancements,” he notes. “That’s the general AJAX definition I suppose, but we’re trying to use it where it makes sense—typically for single action items. For example, our application now supports drag and drop functions without the use of a visual postback,” Cate says. He, like many other codejockeys, cautions against AJAX euphoria.

“Technology shouldn’t define application requirements,” he says. “If you have 10,000 records to scroll through, and you would like to use a Web interface, you have a lot of options. You could send all 10,000 rows to the user at once. You could not send any rows, and use AJAX to get them all at once. Or you could send the first 25, and use AJAX to get the next 25 with a paging/sorting/filtering routine.”

Some wrinkles here and there
One reason codejockeys urge a slow and steady approach to AJAX dev is that there are still a few wrinkles in the fabric. Take XMLHttpRequest, the communicative technology that helps put the asynchronous magic in AJAX, for example. It’s 8 years old and it’s supported by all major Web browsers, but XMLHttpRequest still isn’t a standard. Most AJAX users say this is a non-issue. After all, they point out, XMLHttpRequest is implemented consistently from one browser to the next, and since late last year, a W3C-sanctioned XMLHttpRequest standards initiative has been in the works. Even so, it’s a textbook example of the still-gestating ecosystem of the AJAX app model.

That’s not all. There’s been a lot of talk about how AJAX methods don’t always conform to expected browser behaviors—particularly with respect to the “back” button. If you’re navigating an AJAX-powered site such as Google maps and you attempt to use your back button in the usual fashion, you might find you’ve clicked off-site.

Samy shows security stinks
Most AJAX advocates grant all of these shortcomings—and then some. At the same time, they argue, these issues don’t necessarily have to stand in the way of intelligent AJAX adoption. For one thing, many codejockeys point out, you can break a Web browser’s “back” button without even doing AJAX. App designers don’t pay enough attention to browser behaviors as it is, they argue, so AJAX’s limitations in this respect are livable.

Yes, XMLHttpRequest is not standardized, admits Alliance’s Whittington. “Each browser implements its own way of making the call for you. And yes, it can break the back button and other browser features, but this is mostly a concern for sites that use a single instance page Web site,” he explains. “A SIP site uses one Web page only and then uses AJAX to load the content for the page. In most situations, developers are AJAX-enabling certain areas of a page, rather than the whole page.”

Another potential showstopper is security, particularly in the aftermath of what is widely regarded as the first AJAX-specific attack. Last October, an attacker known as “Samy the Hero” exploited vulnerabilities in the way certain Web browsers parse JavaScript to launch a cross-site scripting attack against the online social network. Samy’s ambitions weren’t entirely malicious–his code, executed in the background on client PCs simply added unsuspecting “friends” to his social network–but he nevertheless took down the site. Not surprisingly, some developers see the exploits of Samy the hero as a mere harbinger of what’s to come.

At the same time, few would argue that AJAX’s enabling technologies (e.g., XMLHttpRequest, server-side JavaScript parsing, or XML) are inherently insecure. See separate story, “The debate over XML and JSON.”