Ajax, promise or hype?

When I first read Jesse James Garrett's article Ajax: A New Approach to Web Applications my reactions were "What a silly name", and "Not really new, is it?" Although both points of critique have been repeatedly and heatedly mentioned in the ensuing discussion, the concept seems to be taking the Web development community by storm. This can mean one of two things: either it's a promise or it's a hype. To decide the case, I offer an annotated link dump.

The article

In his article, Garrett introduces the catch-phrase "Ajax" — an abbreviation for Asynchronous JavaScript + XML — to describe a technique that invisibly fetches bits of data from the server and integrates them into the page the user is currently viewing. Garrett sums up:

Ajax isn't a technology. It's really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

I have several doubts about the viability of this technical overview.

  1. I wouldn't have mentioned XML, because, as we'll see later, XML is not required for an Ajax application (AA?)
  2. For the same reason, I wouldn't have mentioned XMLHttpRequest.
  3. I wouldn't have added XSLT to the stew, because it will never become a viable client side technology. It does the same thing as JavaScript, but in a more complicated way.
  4. I wouldn't have added the last point. Without JavaScript the whole construct will never work, and in any case the DOM and XMLHttpRequest already presuppose the use of JavaScript.

So what remains is XHTML, CSS and the DOM (ie. JavaScript). Hardly a revolutionary new scheme of things, and that could be an indication Ajax is a hype. In fact, it reminds one of DHTML, as Michael Moncur notes:

Now I could jump in here and point out that "Ajax" is a catch-all term for a collection of vague concepts, and we just killed the term DHTML for the same reason, but at least this one doesn't include "HTML" in its name, and besides, nobody likes to pronounce "XMLHttpRequest".

Moncur has a point. Nonetheless, Garrett also has a point. "Invisible" data retrieval is a very interesting technique for improving a site's usability. It is one of the hottest topics of the moment, as I predicted two months ago.

To those who don't quite understand the technology behind the idea I recommend channel c's rather long Ajax: The Next Generation of Web Interfaces. The author (whose name I was unable to find) explains the idea simply and clearly, sacrificing technical detail for broad overview.

The discussion

Garrett's article is definitely a hit. It generated a Slashdot thread (boring), a MetaFilter discussion (interesting), and even a brand new Ajax weblog. A Google search for "Ajax javascript" reveals about 400 articles, not bad for a concept having existed only for three weeks. See also Mike Papageorge's large linkdump.

Although most of these are just short notes on blogs, there is also a sizable group of articles that discusses the proposed techniques and points out potential pitfalls, and I'll quote a few of them below. This is a good sign. When people are thinking for themselves instead of mindlessly parrotting each other, the subject is less likely to be a hype.

There's also discussion outside our tiny circle of web developers. There even seems to have been a talk about Ajax on a recent Java symposium; I found a few quick notes by Ed Burns which could be useful for anyone planning a talk to convince others of the need for Ajax. Unfortunately I couldn't really find out more about the symposium, or an official announcement of the talk, but I have to admire the quickness with which these Java developers seem to be jumping the bandwagon — or, at least, taking the bandwagon seriously enough to discuss it.

Can Ajax narrow the gap between server side and client side? Jeremy Keith thinks so:

[Ajax] straddles the worlds of client-side and server-side scripting [...] To use this technology correctly, developers need to understand both worlds. The concept of progressive enhancement is probably a new one to server-side programmers while the idea of data abstraction may be new to client-side developers.

I certainly don't know anything about data abstraction, while I agree that server side programmers could use a bit of education about accessibility issues and progressive enhancement. Nonetheless, more than accessibility problems I fear the herds of objects Java programmers deem necessary for even the most trivial JavaScript task, so I'm not yet sure if the gap can, or should, be narrowed. Time will tell.


Garrett points to Google Suggest and Google Maps as practical examples of Ajax. This is odd, because the best, and earliest, example remains Gmail. Here the interface silently loads whole chunks of data all the time, and it's closer to a real application than Suggest, and far more complicated than Maps.

Besides, Garrett would have done better not to combine these examples with XMLHttpRequest, or indeed with any specific technology, as Steve Jenson points out:

By defining an architectural style as its building materials and not with its underlying philosophy, it will quickly become obsolete. In fact, it's already obsolete: Google Suggest doesn't use XML for data interchange; just JavaScript arrays. Gmail also doesn't use XML and it doesn't use standards-based markup for presentation. Are they no longer Ajax applications? Of course they are.

That's the problem: while the basic idea is correct, the technical explanation makes less sense than one should think. Unfortunately most blog entries just repeat Google Suggest, Maps, and the XMLHttpRequest-based scheme without thinking about them. That is a bad sign: people parrotting each other means a hype is brewing.

There are, however, plenty of people look beyond Google and create their own examples. Dave Goodlad wrote Combining XMLHttpRequest and Rails to Produce More Efficient UIs, a practical example of the technique — though he doesn't use the term "Ajax" and I have no idea what "Rails" is. Jeremy Keith created an example script you can study and try, while Tomas Baekdal wrote a Business Card Creator. Tomas's script, though hailed as an Ajax example, doesn't have much to do with XMLHttpRequest, since it's not really about data retrieval or storage but about interfaces. The interface he created is so smooth, though, that I include it anyway.

Examples don't have to be scripts, they can also be thought experiments to take Ajax a few steps further or to compare it to other technologies. Kevin Smith proposes to use XMLHTTP as an analysis tool, which is an interesting idea, while Jonathan Boutelle has an excellent comparison of JavaScript and Flash, though he insists on calling both RIA's, whatever those may be.

The number of practical examples and experiments is a good sign: hypes don't generate so many and so varied code examples this quickly.

Old ideas

The ideas behind Ajax are not new. Some bloggers point to Apple Dev's Remote Scripting with IFRAME (2002) as the first article to deal with data retrieval. Matthew Haughey has done some experimenting back in 2001, and is glad to see these techniques come to the fore once again. I myself could go even further back in time to some inconclusive hidden frame experiments I did in 1999.

In theory asynchronous data retrieval became possible in 1996, when Netscape 2 was released with frames and JavaScript support. Nonetheless those early browsers weren't really suited for creating smooth interfaces, and when the browsing technology became better around 2001/2, cutting edge web developers had lost much of their interest in JavaScript because much of it was so pointeldly useless.

This venerable pedigree is in itself a good sign. If people have been working on it since times immemorial the technique must be a promise, though a postponed one.

So on the one hand data retrieval is an old technology. On the other hand it's as yet untried, as Cameron Adams explains:

Although it has been around for a while, in terms of its usage JavaScript data retrieval is still a very immature technology. The uses which I have seen are either for manipulation of form data (Google Suggest), or complete web applications (Google Maps, GMail, map.search.ch). The reason that there is no inbetween is because, as with all JavaScript solutions, JavaScript data retrieval has an Achilles heel: you can never rely on a client to have it or allow it.


Which brings us to accessibility. Should a data retrieval application be accessible? If so, how?

Although accessibility is always a good idea, it would be interesting to try to define cases in which a site may require JavaScript and send noscript browsers on to a "Sorry" page. Very large and involved applications meant for a specific target audience may require their users to support JavaScript, but a general web page aimed at a general audience should not. Where do we draw the line?

Nonetheless we should at least try to make Ajax applications accessible. Simon Willison sees two ways:

Either provide a fall-back system where the site remains useful without its Ajax enhancements, or provide a whole separate interface that works without scripting.

I intensely dislike the second option, because it'd basically mean creating a second site, with all budget and planning problems that entails. So I'd like to ensure accessibility within a JavaScript framework.

An accessibility proposal

In theory the solution isn't even that complicated. I envision the following:

First make sure all chunks of data are available as HTML. This could mean XMLHttpRequesting HTML documents, or it could mean writing a server side script that can serve chunks of data either as XML or as HTML, as circumstances require.

Next, make sure that all links that trigger data retrieval are actual old-fashioned hyperlinks with a custom attribute to trigger the data retrieval:

<a href="moredata.html" advancedDataRetrieval="true">More data?</a>

Finally, write a script that handles the data retrieval through an onclick event handler on these links:

var checkSupport = [check browser support in an as yet unknown way];

window.onload = function () {
	if (!checkSupport) return;
	var x = document.getElementsByTagName('a');
	for (var i=0;i<x.length;i++)
		if (x[i].getAttribute('advancedDataRetrieval'))
			x[i].onclick = function () {
				return false;

If the browser supports data retrieval the href of the link is passed to retrieveData(), which starts up the XMLHttpRequests, hidden iframes or whatever. If the browser doesn't support it, clicking on the link simply loads the HTML data chunk as a new page. You'll lose the smooth interface, but the data itself remains accessible.

Of course this will become a much more complicated task in actual applications, mainly because noscript browsers lose huge chunks of usability. The principle remains valid for all data retrieval mechanisms, though.


Which brings us to the one point that is hardly being mentioned, even though it should be the most important one. Jason Fried explains:

However, let's proceed with caution. What we're talking about is technology, not the user experience. Ajax-based apps certainly have the potential to produce a better user experience, but good experiences never come by default. Good experiences aren't plugged in. Good experiences are crafted by thinking about people, not technology.

He's completely right. While dozens of blogs and articles, not to mention most of this entry, talk about technology, the point of Garrett's article was (or rather, should have been) to point out the usability benefits of an Ajax approach. Garrett's explanation is too short for my taste:

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. [...]
It represents a fundamental shift in what's possible on the Web.

Sure, but how? That's what I'm missing in the current discussion. Jeffrey Veen doesn't go into detail, either:

With Ajax, we can create Web-based experiences that feel fluid and native. We won't have to rely on clunky navigation or plugins to enable users to achieve their goals.

I don't get the "clunky navigation" bit, and I'd loved to have seen a few more examples. I can vaguely make out some possibilities, but I'd have welcomed an in-depth usability discussion of the idea. Besides, if we can't improve usability by using Ajax we shouldn't bother with it. There's plenty of bad JavaScript floating around the 'Net as it is.

The fact that a usability discussion is largely lacking, and that the short notes that have been written remain rather vague, is a bad sign. Ajax might be a hype after all.

Ajax, promise or hype?

So what's the verdict going to be? Promise or hype? Let's review the arguments.

Right now Ajax hangs in the balance. Reasoning from the articles and blog entries that are available today, Ajax could be either a promise or a hype. That makes me lean to the hypey side, because I feel that if something "could be a hype" it probably is.

But — and this is a big but — any serious treatment from a usability point of view will swing the balance firmly back to promise, and will convince me of Ajax's usefulness in web development.

If you believe in Ajax, if you want it to succeed, talk about usability, not about technology.

This is the blog of Peter-Paul Koch, web developer, consultant, and trainer. You can also follow him on Twitter or Mastodon.
Atom RSS

If you like this blog, why not donate a little bit of money to help me pay my bills?



Comments are closed.

1 Posted by Jim Ley on 13 March 2005 | Permalink

Opera has a hobbled implementation of XMLHTTPRequest that is tested only against GMail, and offers nothing like MS's reference implementation or Mozilla's clone.

You can do stuff with it, but don't expect to do anything complicated.

2 Posted by Brent Ashley on 13 March 2005 | Permalink

Historical footnotes:

While Eric Costello's Apple article definitely raised remote scripting's profile in 2002, Erik Hatcher's IBM Developerworks article in Feb 2001 was one of the earliest high-profile articles on the subject.


I released the iframe-and-layer-based JSRS in 2000 specifically to provide cross-platform remote scripting to those who could not limit themselves to Microsoft's Java-based Remote Scripting. At the time, I was active in many scripting and DHTML newsgroups and forums, so I built it because JSRS filled what was a void at the time. There were plenty of successors - some superior to be sure, but historically I think JSRS preceded them.

3 Posted by Tom on 14 March 2005 | Permalink

Ajax and Accessibility is a good read.


4 Posted by Dean Edwards on 14 March 2005 | Permalink

Yes these methods have been around for a long time. A bit of hype was needed though to bring them to the fore. Now at least project managers will take web developers seriously when we suggest using such techniques!

My only concern is that there will be an insistence by some on sticking too rigidly to the hype. That means using XML where it isn't necessary. XML can be overkill in a lot of situations. This is where the original article that started the hype is at fault. None of Google's killer "Ajax apps" use XML so they are not really Ajax are they?

Anyway, good article PPK.

BTW. "Rails" is Ruby on Rails. An OO framework which is also getting a lot of hype recently (but with good reason).

5 Posted by Jim Ley on 14 March 2005 | Permalink

Yep, these methods have been around for ever, they even predate DHTML (hidden frames to populate form elements are as old as NN3, I turned up example usenet posts from 1996 on my blog).

The interest now is simply due to the client-side scripter beginning to exist as a speciality, and the monoculture that IE dominance has given us.

6 Posted by Jacob on 15 March 2005 | Permalink

I like the look of this method - it provides a hassle free (well, we can only hope) way to do what would normally need a hidden iframe (or whatever) - but for now at least, what's wrong with a hidden iframe? Yes, it's a bit clumsy and has a couple of other problems, but they're solvable, and more importantly it *works*, usually even on older browsers to an extent.

I appreciate the advantage of this new Ajax thing, but I would say (as have others) that it is only a name stuck on ideas that really aren't that new.

One thing that does sound interesting is that I've not worked out how to send POST requests from javascript using the hidden iframe (where GET is of course easy) - this means that certain characters have to be encoded to keep the url valid, and also the data sent is limited in size etc. If I've understood it correctly, ajax could mean that pretty much any data could be sent without difficulty - potentially very useful. However, I must say that it still isn't widely supported. Opera for example, supports it, but from what I've heard it's quite buggy. Also, I haven't tested them, but what about older Mozilla / IE browsers? Not to mention all the others.

Good article :-)

7 Posted by Woodspire on 15 March 2005 | Permalink

Here is a AJAX toolkit: http://absinth.modernmethod.com/sajax/index.phtml

8 Posted by Fernando Gomez on 15 March 2005 | Permalink

A comment regarding PPK's observation that "[XSLT] does the same thing as JavaScript, but in a more complicated way". Suppose you have a web application that performs tasks like data validation and data visualization using JS. But since you can't or don't want to depend on the client's JS capabilities, you need some alternative method to implement the same tasks on the server. You could re-write similar visualization and validation scripts using, say, pure PHP; but now you have *two* versions of esentially the same code: one for the client, another for the server. When you reach a certain level of complexity, maintenance of both versions becomes tedious and prone to inconsistencies. On the other hand, using XSLT you could run the same code on both client and server. I've not yet implemented this approach, but I see no other practical solution. What would you suggest for this type of situations?

Jacob: you can use JS to submit a form whose method property has been set to "post"; I wonder what problems you've found doing that.

9 Posted by Casey on 15 March 2005 | Permalink

Good article.

I think that Ajax is just the next swing of the thin-client/fat-client pendulum that's been amusing software and hardware developers for so many years.

The best thing that can come out of Ajax is the notion of a rendering engine - no matter where it lives - being a separate piece of a (web-)app. If it's abstracted properly, a UI engine can then generate server-side HTML, client-side DOM, or fat-client native-OS windows, all from the same data sources. Like everything else about Ajax, this is already possible, but the more thoughts go in this direction, the more we have to benefit from portable and accessible front-ends to the data we so dearly love.

(I'm the unidentified author of the "Ajaz" overview I wrote at http://caseyporn.com/blog/archives/000675.html. You can attribute me as "Casey" if you want.)

10 Posted by Dylan Schiemann on 16 March 2005 | Permalink


Dojo has just released its first profile build at http://dojotoolkit.org/intro_to_dojo_io.html (article) and http://dojotoolkit.org/dojo_browserio.tar.gz (code). In this build we have worked to provide back button and bookmarking support, a small step towards making these types of apps more usable. As you know, we've been working to build a better toolkit for JavaScript apps. Something that this build shows off is our ability to create very small, truncated profiles of our larger library/toolkit, so that people can still use small lean pieces of our code when they only need a few of the many features we are working on.

Many of us personally hate and detest the name "ajax". We think we should wash JJG's mouth out with ajax for creating such an ugly and uninspired name for our field. :)

Thanks for the article.


11 Posted by stylo~ on 16 March 2005 | Permalink

The annoying thing is, beyond a highly inaccurate and unnecesary new name, the Adaptive Path article didn't even cite past usage and Brent Ashley, who has probably done more than anyone for remote scripting in the past.

I don't think remote scripting is hype, but simply

1) highly visible because of google, much like major sites using css layouts surprise some people, and

2) much easier to do now that xmlhttprequest is supported by 4 browser groups - though IE's, strangely enough, is increasingsly hobbled by strict security settings. They need to get their act together and move it off ActiveX and into js, and Opera really needs to implement what parts they haven't yet before they release a hobbled v8.

12 Posted by stylo~ on 16 March 2005 | Permalink

On the subject of usability, I should add that for simple GETs, I don't even recommend xmlhttprequest in IE, rather dynamic scripts; that way you don't have to worry about security settings. Also works in IE Mac, too, so an extra browser supported.

13 Posted by Jacob on 16 March 2005 | Permalink

What I was doing was an experiment really - I had set the action property to a javascript function which then sent a url (+ 'get' data) with certain form data to a php script on the server, which produced xml to be displayed using javascript. In case you're interested, I was building a js / php / mysql text based adventure - just to see if I could! 'get' was fine for this - I could for example set the url of a hidden iframe to whatever it needed to be - but I couldn't see how to do 'post' without re-loading the page - i.e. by actually sending the form.

14 Posted by Alex Aguilar on 16 March 2005 | Permalink

Rails is a ruby web framework

15 Posted by Stephen Quattlebaum on 16 March 2005 | Permalink

All this hype over Ajax really surprises me. I was using XMLHTTP with IE 5 all the way back in 2000 to load tables and drop-down lists without refreshing the entire page. I didn't realize that I was a pioneer 5 years ahead of my time :-)

16 Posted by Adam Michela on 17 March 2005 | Permalink

Good article. My take...

17 Posted by Jim on 17 March 2005 | Permalink

I agree with Stephen Q. above. I had been familiar with XMLHTTP combined with DHTML in IE going back many years. The major difference to me is that it now has a sexy name (along with the ever important letter J which implies "java=open").

The advantage to me is that it became "in vogue" at an opportune time, as I recently came across a high profile application that would benefit from its use. Now as I try to sell the skeptical customer on the approach I can turn to them and say "See, that's what Google is doing", to which I can expect a "We want that too!" response.

18 Posted by Sergey on 17 March 2005 | Permalink

I'd just like to chime in my 2 cents in support of AJAX. We've been using a similar "invisible" XML-based comunication since 2001 in our platform to provide web-apps for several of our Fortune 500 clients. Even though this was our initiative, this ended up playing a large role in securing/keeping accounts.

19 Posted by Danno on 19 March 2005 | Permalink

I think the two things that are making people pay attention are that 1) Google is doing it and 2) AJAX is a really cool name.

Now maybe that's hype, but if the stuff below it is solid, then it's good publicity for a nice set of techniques that can do good things.

20 Posted by Mike Propst on 20 March 2005 | Permalink

Jim (Comment 17) really hit the nail on the head. A few years ago when I first tried out remote scripting (using hidden iframes, not XMLhttpRequest), it was fun but there was really no way to get a client to want it, or a really great example of what it could do. It's fun for a developer to see a page get data without refreshing, but it doesn't in itself wow people the way a popular app like Gmail does.

This is one prime reason why I don't think it's hype at all-- Google's apps as well as examples like Baekdal's business card creator provide a great insight into how to make web apps into something other than a series of boring and one-sided forms, and the technology's popularity seems to have made all that possible. Great article all around though; as much as I think this technology will provide real promise, you have to cut through the hype first.

21 Posted by John Hansen on 24 March 2005 | Permalink

"As much as I think this technology will provide real promise, you have to cut through the hype first"

I think that about sums it up for me too. However, the craze of using client-side validation with remote scripting scares me a little. Remote scripting is definitely no substitute for server-side validation when it comes to security. Those who succumb to the notion that their form submission script is safe because they checked the values along the way purely using AJAX are doing themselves and their viewers a disservice. The safest way to validate code is still after all the form data has been submitted, directly before manipulating/storing said data.

Also, most simple cases like Baekdal's business card creator can be replicated using purely client-side javascript. The hype side of "AJAX" is the temptation to re-create the wheel as a status symbol, and this is what really makes me cringe.

22 Posted by Dave Cline on 25 March 2005 | Permalink

Ajax fervor is like taking credit where credit is NOT due. We've all been doing XMLRPC/remoting/silent data retrieval in Web pages for years - and doing because it made sense. Not because we wanted to take credit for an obvious combination of existing technology. Garrett was just looking for writing material and notoriety. Bhah I say!

23 Posted by Bruce Grant on 25 March 2005 | Permalink

As already mentioned, not only is there is nothing new about "AJAX", I was a founder of a company that created a Delphi-like tool for generating complete desktop-like applications in the web browser from as early as 1999: http://www.sys-con.com/webservices/article.cfm?id=565. Note the screenshots: Java dev tool to generate XML that is brought into the browser and turned into rich UI using JavaScript, HTML and the like.

24 Posted by Buddy Burden on 30 March 2005 | Permalink

Here's another example of a system that provides many (if not all) of the Ajax philosophy that's been around for years: http://www.openthought.net/ . I've used OpenThought very succesfully several times. I don't believe it uses any XML, but it does use Javascript to transfer info back and forth from/to a hidden frame.

25 Posted by Robert Nyman on 1 April 2005 | Permalink

Interesting article.
Personally, I've doing this for some years now, exclusively in admin interfaces, and it's fascinating that it has become a hype now and not sooner.

I agree with Dean Edwards that it might need the hype so one, as a developer, can point to different articles and implementations when one wants to use it in a project and have the need to persuade, for instance, project managers.
Then, of course, XML doesn't have to be necessary in every case (although it is a format I generally prefer).

Usability definitely is a big issue, and a lot of focus has to be spent on that.

However, the comment "It does the same thing as JavaScript, but in a more complicated way" shows a lack of understanding of XSLT, which in my opinion is a very strong language when it comes to data handling.
Please read more at http://www-106.ibm.com/developerworks/xml/library/x-xslt/?article=xr

26 Posted by Vesa Piittinen on 2 April 2005 | Permalink

XSLT has one drawback: it doesn't have as big browser support. Opera is a one bigger name that doesn't work with XSLT (unless they're coding the support in Opera 8... haven't tested). It is good though that IE and Firefox support it, which are the two most used browsers nowadays. I don't actually know how good the overall support is... I have no idea if XSLT is supported in Safari or not, for example.

27 Posted by Robert Nyman on 2 April 2005 | Permalink


I agree with you. XSLT isn't always the best option when it comes to doing it on the client-side; only when it's a IE/Firefox only solution (for instance, an admin interface).

I just wanted to point out that it isn't the "...same thing as JavaScript, but in a more complicated way".

BTW, Safari will/has added support for XSLT now:

28 Posted by Dawn Green on 13 April 2005 | Permalink

I laughed out loud when I read Garrett's FAQ where he asks in his perfect marketing gimmick, "Did Adaptive Path invent Ajax?" We like to use our own dose of marketing at our offices, where we prefer to call it by our own in-house brand, ThunderScripting. :)

29 Posted by hxa7241 on 15 April 2005 | Permalink

David Flanagan (javascript definitive guide) suggested DHTTP as a preferable name.

-- its more expressive of its meaning, relates neatly to DHTML, and removes the 'marketing' taint.

30 Posted by Peter on 16 April 2005 | Permalink

I found a very useful wrapper that can be used in Microsoft .NET Framework with about 2-3 lines of code. It will create javascript wrapper function that will call the .NET method.

See link: http://ajax.schwarz-interactive.de/csharpsample/

31 Posted by Stefan on 18 April 2005 | Permalink

This is really funny. I think I wrote my first web "application" (a shopping cart) in 1998. The app didn't use DHTML, iframes or whatever at all, because such technologies even didn't exist! Instead it made use of a traditional frame which had a dimension of 0x0 pixels and was thereby hidden from the user. With such a setup one already could do some nasty things like dynamically loading HTML pages in the background, getting data from the server or sending data to it using GET requests. With frames one could also dynamically create HTML pages using only JavaScript. By the way, the first books about Java applets teached the use of such callback mechanisms. Hell, what's new about it?

32 Posted by Uberpu on 19 April 2005 | Permalink

I have implemented a round trip version of AJAX and use the libraries extensively to manipulate data and return it to the database via XSU. Javascript whomps the heck outta that crazy flash actionscript, and is a lot less picky about the validity of XMLsets. AJAX is good.. Here is a comprehensive set of all the NYState laws that has to be called.. 7000 in a drop box (selects are so over...) Ex: http://www.uberpu.com/Utilities/

33 Posted by rob on 28 April 2005 | Permalink

Follow-up to my post. My problem appears to be fixed, and apparently was due to the fact that the server-side .Net code was ignoring code it didn't think various useragents would support. It would just omit them in the output and not even mention the fact. Thanks, MS.

34 Posted by Koranteng Ofosu-Amaah on 9 May 2005 | Permalink

Exactly right... There's nothing new under the sun and this is the kind of thing that many of us have been discussing in various forums e.g. wdf-dom

I've been writing State of the DOM addresses every year and this was last year's version:

On GMail and DHTML Architecture again

I'll continue to do so but as this Ajax coinage shows, sometime you need to have snappy titles. Also perhaps it's just that now people are willing to listen.

35 Posted by Jim Plush on 24 May 2005 | Permalink

I've been deep in the world of AJAX lately (Asynchronous JavaScript + XML) and as I read articles I see people bitching about how someone just gave a name merging several technologies together CSS, Javascript, Serverside language, XML etc... I'm actually glad someone gave a name to this method of development. Why? Because this is the point of design patterns. Giving a common name to a solution to a problem. If you were talking to a developer and you said "I'm going to make a form then when a user clicks I'm going to use some javascript to send a message to my server then that'll trigger a javascript function that changes some CSS values so I can show the user something new without refreshing the page." Thats a mouthful. How about just saying "I'm going to implement this form via AJAX so no refreshing is needed" Now I know exactly what you're trying to do in one short sentence. Just like a design pattern gives a short name to a solution.

36 Posted by DAG on 24 May 2005 | Permalink

Excellent article.
In addition to the many comments pertaining to the notion that AJAX is nothing new, I offer an in depth read about a complete Rich Browser Framework (RBF). We need to go beyond just the asynchronous value add that Ajax describes. We need to establish a complete MVC architecture client side and loosely couple it with a distributed data model. Such a framework would provide the open source community with the technology necessary to create really powerful rich internet applications.

Read the Rich Browser Framework section of this article: http://www.research.ibm.com/journal/sj/432/ponzo.pdf

If you have access to Rational Application Developer v6 this framework is available today. Unfortunately it is currently only available for Java.

I think an open source implementation of this JavaScript-based RBF would be beneficial to open source web developers especially if it was enabled for PHP. Anyone agree?

Maybe such a framework could also be augmented by DHTML Accessibility (an accessible JavaScript UI widget library). See www.mozilla.org/access/dhtml

37 Posted by Jane Saunders on 7 June 2005 | Permalink

Excellent article and a superb resource as always. Your writing is just fun to read and while I find myself always skimming, your writing made me read the article through.

As for AJAX examples that work nicely either with javascript enabled and without I have found http://www.seedler.org they seem to be handling both cases quite well.

Thanks again,