In-Depth
AJAX changes everything, believe it
- By Stephen Swoyer
- May 1, 2006
There 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
THE AJAXIFICATION OF ENTERPRISE APPS
- 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 myKB.com, a developer of knowledgebase software. “AJAX for myKB.com 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 MySpace.com 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 MySpace.com 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.”