Adaptive Path logo

Adaptive Path
product experience strategy and design

« The forthcoming film adaptations of | Main | Quest for NyQuil »

February 20, 2005


When Google introduced Gmail last year, I started formulating some ideas about how the approach they took could be generalized and combined with some other emerging technological trends -- a new way of creating Web applications that could deliver a higher level of responsiveness while still building on all the knowledge we've accumulated about traditional Web technologies.

After using this approach on some client work, I became even more convinced that this represented a major turning point for Web apps, and Google's subsequent projects (like Google Suggest and Google Maps) only confirmed my opinion.

Ajax is the name I came up with as a shorthand way to refer to this new class of applications. And in case you can't tell from what Lane and Peter and Jeff have written, all of us at Adaptive Path are pretty excited about the new possibilities Ajax opens up for Web interaction design.

Obviously, there's a lot more to be written about Ajax, and this essay just lays the groundwork for what's to come.

<=> | February 20, 2005


Curious whether there's been any thought given to the types of applications that this technology is appropriate for (or not appropriate for). For example, are there security, reliability, dependability (or other -ility) constraints that such technology could not easily meet?

Posted by: Medley | Feb 22, 2005 11:08:49 AM

I don't usually like to lean on the theoretical/philosophical stuff as it relates to technology, but are Ajax apps really web apps if nothing in them has a URL?

Like, I can't offer a permalink to a message (or a state) in my gmail inbox very easily because it all exists as a combination of script and markup. In the same way, I can't bookmark a particular message in gmail or refer to a dropdown list in Suggest. THINK ABOUT THE URLS!

Posted by: Anil Dash | Feb 22, 2005 11:14:36 AM

The presence or lack of URLs to resources inside of a web app are very possible and not exclusive of this more dynamic web app approach as you have suggested. Google has simply decided against (or has not yet implemented) such a structure.

I believe the term "Ajax", as a trademark of the Colgate-Palmolive company and well-known brand of household cleaning products, is a poor choice for the collective technologies you describe. It is true that use of these technologies is not widespread yet and is being popularized chiefly by Google, but it is also prudent to note that these technologies have been around for several years at least and should not be referred to as "new."
I am glad that you have discovered the wondrous possibilities that XMLHTTP, JavaScript and XML can bring to the dynamic web app field, but I emplore you to respect the field in its autonomy and those developers that have come before you rather than proclaim yourself a pioneer or mislead your readers in any other way. That said, thanks for your contribution to the field.

Posted by: Brad Fults | Feb 22, 2005 1:02:36 PM


As someone who unfortunately spends too much time on the phone with lawyers, might I suggest a less liable name? How about "Responsive Internet App" or "Responsive Web App". Not sexy, but at least it covers the bases and avoids litigious megacorps.

Past the name though, it occurs to me that the way you present these technologies as something that you can just "mix in and go" with is both disingenuous and dangerous. From firsthand experience, I can attest that it is incredibly simple to write a JS-powered UI that can leak in the tens of megabytes of memory on IE, but mind-numbingly hard to debug (esp if someone more junior did the dev work). What seems like good development practice in almost any other language is truly abhorrent to good JavaScript style. In short, the knowhow and the tools to build these kinds of apps aren't nearly as widespread as I think your article leads people to believe. You don't even touch on the hard optimization problems. All of the example sites you point to have at least one FTE dedicated to the care and feeding of these UIs, and I don't think your readership is well served by the way you gloss over the remaining cross-browser deficiencies and the challenge of degrading gracefully.

There are people working on tools to make this easier. We have been for years. We (the Dojo Project, would love to work with you to make these kinds of technologies and techniques easier to deploy. But first we need to acknowledge that this isn't all rose petals and sunshine.

And please, can we call it something else?

Alex Russell

Posted by: Alex Russell | Feb 22, 2005 3:51:19 PM

I'm working with "ajax approach" on some php projects and things are going very promissing. I pretend to release all code as free software.

to reach desktop look'n'feel, we just have to change HTML for XUL and that's it! or not!? :-)

anyone who want to chat about that, please, drop me an email.

Posted by: andré camargo | Feb 22, 2005 5:30:32 PM

Another vote for call-it-something-besides-ajax. I'd really hate to work on "soap" full time.

Posted by: David Schontzler | Feb 22, 2005 6:16:58 PM

Has anyone written more about Ajax Engine design/implementation? I'd be interested to learn more about the general services provided by an engine (opening connections, notifying when new data is available, general event handling, parsing xml, whatever-else-an-Ajax-Engine-does).

Posted by: Rich Davies | Feb 23, 2005 11:34:54 AM

Kudos, it's great to see such focused attention on a subset of web technology that many of us in the trenches have been using and excited about for years!

on2me is the one Ajax-style app I've been developing lately that I'm quite proud of, a simplistic dhtml web IM/chat, something I've toyed with since before the Jabber days. I'm happy to share if others want to re-use the work I've done.

Along the lines of other comments, although the concept and process is proven, anyone who's built real apps on these techniques know the painstaking process it is to get everything running smoothly and remain compatible, web development at this level is an incredibly finniky thing. Glad to see more focus on this tho, there's still a huge amount of potential out there.

Posted by: Jeremie Miller | Feb 23, 2005 12:21:29 PM

This AJAX approach is shiny, but it has awful implications for disabled folks. Much of the Web is already off-limits to blind people thanks to thoughtless use of Javascript, Flash, etc. I can see no way of implementing Section 508 compliance with AJAX, short of a completely independent interface. And once you start maintaining two interfaces, one of them is bound to fall behind - and I bet it's not the shiny one!

Posted by: Jacob Rose | Feb 23, 2005 1:12:51 PM

JavaScript have its limitations. Google Maps is not very responsive comparing with a Java map here
If you require some advanced user experience, you will need more than JavaScript. However what Ajax did with web browser is amazing.

Denis Krukovsky

Posted by: Denis Krukovsky | Feb 24, 2005 7:33:21 AM

Terrific article, and great comments as well - My thanks to Jesse and all the commenters...

Quick question: can anyone point out any active discussion forums for this topic?

MSDN's discussions in scripting.jscript isn't bad, but not great either...

Posted by: Matt Stuehler | Feb 25, 2005 7:03:19 AM

Nice discussion. Here's my dime ...

Re: Section 508. I'd say client-side scripts are best leveraged as an enhancement that gracefully degrades whenever possible. Now I agree, that doesn't happen as often as one may prefer (and in some cases it might even be unnecessary due to the context), but there are some shining exceptions out there. Take sIFR for instance. It uses JavaScript and Flash in a lovely one-two punch, but what if you don't have any JavaScript or Flash support? No problem! The underlying content remains intact and accessible.

Asynchronous techniques would do well to follow a similar path if at all possible. If the user agent doesn't support async, have the tried and true method to fall back on. Better yet, take it a step further: Instead of developing two different kinds of functionality in parallel, add asynchronous support to already-existing functionality. This way you aren't building the same house twice. You're merely providing two different entrances, metaphorically speaking. (I know, it probably isn't as cut-and-dry in practice ... but then we all love a challenge, right?)

Re: Memory leaks. Tell me about it, it's a minefield out there (and I have the war wounds to prove it). Be sure you have your JavaScript closure gear on! Peter-Paul Koch has another (more recent) thread on the subject as well.

Re: Trademark infringement: I was going to suggest Jesse consider incorporating the more canonical ECMAscript but - let's face it, Aecx just doesn't have the same ring ...

In short: Be considerate, be environmentally responsible, keep it simple ... and be creative.

Posted by: Joe D'Andrea | Feb 26, 2005 10:14:28 PM

There are three points about Ajax I'd like to make:

1. Ajax is hardly a trademarked name, or at least an easy one to dispute, as it is the name of the hero from the ancient Greek mythology (also known as Aiant or Aias). He fought and died alongside Achilles in the Trojan war.

2. AJAX might actually be an appropriate name if it used SOAP to communicate with its server-side engine. There is no reason why it shouldn't beacuse SOAP is a standard which enables one to open the server-side for communication with any client application, regardless of its technology.

3. As I already posted in a comment to the Sitepoint Blog:

I've recently realized that anyone doing a Web applications is unavoidably making two applications: one server-side, and another client-side, unless the client side is nothing but pure HTML with no code to be executed client-side. The only thing that connects the two is the HTTP (or other similar) protocol, and the data passing between them.

It is irrelevant what is the nature of the client application -- whether it's installed locally (classic desktop app, HTA or XUL), or it's transferred once (applet, flash, "ajax") or on each page request (standard javascript). In my opinion, it is extremely important for Web developers to realize that, and construct their applications with that in mind, or we end up with such monstrosities as portlets or ASP.NET.

Web developers should break with the idea of a "site" or "page". Javascript, with HTML/CSS for presentation definition and XML for data transfer.

Oh, and yes:

Posted by: Berislav Lopac | Mar 7, 2005 3:49:03 AM

I feel that the term "Ajax" is a misnomer. Instead, we should stick with the older term "Remote Scripting", as "Ajax" is too technology-specific and buzzword-ish in my opinion. First, let's look at each part of your proposed definition:

1) A for ASYNCHRONOUS: Well, it's less synchronous than refreshing the entire page or issuing a blocking call to the server, but a true async approach would involved the ability to conduct a "server-push" update of remote content, rather than the current Remote Scripting "polling" approach.

2) JA for JAVASCRIPT: JavaScript is the most popular client-side language today. However, MSIE supports VBScript by default, and optionally PerlScript too. In the Mozilla camp, Gecko 2.0 may include multiple language bindings (e.g. Python). So, the term for Remote Scripting shouldn't necessarily be tied to a single language, however predominant it may be today!

3) X for XML/XSLT/XMLHTTPREQUEST: The poster child of the Remote Scripting world, GMail, doesn't even use XML for communication -- it uses JavaScript notation (a.k.a. "JSON") for data interchange instead of XML, for a number of good reasons. Furthermore, Google Maps, one of your other cited examples, uses a hidden IFRAME rather than XMLHttpRequest (IIRC). So, these don't fall under your definition of "Ajax" -- or do they? Who's to say?

Remote Scripting, on the other hand, covers any other mix of technologies you or I wish to implement (say, communication via an IFRAME, Flash movie, cookies, or the like). IFRAMEs in particular are a proven method; I've been using them for years, and recently wrote a server communication API using IFRAMEs. Should that be excluded from a proposed definition merely because it doesn't use a technology beginning with the letter "X"?

Secondly, "Ajax" is more of a marketing buzzword than a valid description of a technology. Granted, your marketing experience is far more extensive than mine, but I don't feel we need a buzzword for the technique at all. Try telling someone your site uses "Ajax", and they'll ask for an explanation, whereas with Remote Scripting at least they can get an idea of the concept. Techniques rarely need buzzwords; after all, you don't see anyone mooting the term "ePhotoMation (tm)" for adding images to sites!

Futhermore, as other posters have pointed out, "Ajax" is duplicated in many other trademarked areas. Google "Ajax", then Google "Remote Scripting". Guess which returns more relevant results and less trademarked brands. I'm not a lawyer, so I'll leave this up to others to discuss.

So in conclusion, any definition should cover the broad technique rather than a specific technology; "Ajax" certainly fails this criteria. Its definition is too narrowly focused, as it's possible to implement Remote Scripting techniques using exactly NONE of the JavaScript, XML, XSLT or XmlHttpRequest technologies. I almost feel like knocking up a VBScript-powered IFRAME-communicating script that passes data via evaluable strings, just to prove the point ;). Not including technology names in the definition of "Remote Scripting" is a good thing, as it'll future-proof (and present-proof) the overall technique.

Posted by: Angus Turnbull | Mar 8, 2005 3:06:58 PM

AJAX is the top soccer club in my city Amsterdam.

As we already working on building RIA devtools on top of industry standards for the past 5 years its funny to see that my area of work now relates directly to my favorite soccer team.

Posted by: BackBase | Mar 31, 2005 5:36:30 AM

Read your article on Ajax with interest. I was doing something very similar back in '98 or therabouts for in-house applications - though I was transferring data as CSV rather than XML. Only worked in Netscape 4 too, but I could get away with that for internal stuff.

It blew people away, because they were used to the click submit/wait wait wait/page reloads style of web app, and I was using Javascript, socket connections directly to the host application, and frames and layers and getting sub-second response times.

Very slick, but never quite robust enough (the socket connections tended to hang every so often, and you had to kill Netscape and restart it). And very non-portable.

The tools are a little bit better today.

Posted by: Pixy Misa | Apr 21, 2005 4:37:28 AM

This AJAX approach is shiny, but it has awful implications for disabled folks. Much of the Web is already off-limits to blind people thanks to thoughtless use of Javascript, Flash, etc. I can see no way of implementing Section 508 compliance with AJAX, short of a completely independent interface. And once you start maintaining two interfaces, one of them is bound to fall behind - and I bet it's not the shiny one!

Posted by: bt2net | Oct 9, 2005 3:10:22 AM

The comments to this entry are closed.