Ajax
JJG over at Adaptive Path has a nice article on rich clients in their current incarnation of asynchronous JavaScript and XML. He calls this Ajax. It's good and worth reading if you're not already familiar. I have one small problem with it:
By defining an architectural style as it's building materials and not with it's 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.
What's amazing here isn't that there are rich clients on the web that use an asynchronous tier. What's amazing is that they aren't built using proprietary technology; they're not Flash, Java, or ActiveX.
Because they're not proprietary, we can, as JJG says, use the techniques we already know and are well deployed. This is also true for scaling Ajax applications; we can use the stuff we already know; Etags, Range, If-None-Match, etc.
posted by Steve Jenson at 11:57 AM
![[Atom Enabled]](http://saladwithsteve.com/valid-atom.png)
9 Comments:
Couldn't you make the case that the underlying philosophy is that the data is plastic? Then you could argue that Gmail and Suggest rolling their own is a flaw. (Funny... we've had this battle ne discussion for as long as I've known you.) If you say that the standard for data exchange is JSON instead of XML, then you're back in business.
Very interesting stuff BTW. This whole thing has completely changed the direction I'm going in as a developer.
2:16 PM
I have no idea what you mean by 'plastic'. IIRC, Gmail and Suggest were around before JSON showed up.
6:00 PM
You don't hear people use plastic in that way much any more. Now it's all about disposable bags and cups.
2b: capable of adapting to varying conditions: PliableXML and JSON are plastic. You do mold them into many different things using many different tools. The data lives beyond the immediate needs of the program.
Pure seperation of data from design has always been one of the web's utopian goals, constantly being overrun by innovation. Tables, Frames, Flash, DHTML, and now XMLHttpRequest all pushing the envelope of what can be with little concern for it's plasticity.
Google doesn't have to worry about that as much because it's an 800 pound gorilla (be it a very sexy sweet and cuddily one). It has its own internal dynamics. If it doesn't innovate (push the envelope), it dies. It's technology has reached the point where it has its own gravity which significantly alters its priorities when interacting with others. However, for the online community interoperability is everything.
XMLHttpRequest poses a lot of challenges from a usibility perspective. What impact does it have on blind users? Spiders? Linking? Providers can use it as a weapon to control what people can do with their content. All things that erode what are otherwise assumed standards of how things work online.
Without a foundation in standards the longterm impact would most likely be a net negative.
7:31 PM
Funny you should mention JSON. JSON is data that is also code. Check and Mate, old friend. ;-)
You're definitely right that XmlHttpRequest presents many problems for accessibility. There are definitely people here at Google who care deeply about that so hopefully the situation will improve.
8:40 PM
ARG!!!
4:56 AM
Steve,
I completely agree with you that the AJAX name is too specific for it's own good. To my mind the right name for these things are "JavaScript RIAs". This allows us to clearly distinguish AJAX from Flash or Java-based asynchronous web experiences, without specifying the format of asynchronous data (which could be raw text, a proprietary protocal, or even a binary protocol in the case of Flash).
I liked your phrasing of the problem so much I quoted it in my blog ...
Regards,
-Jon
10:23 AM
I'm not sure about that phrase "JavaScript RIAs", because of the "Rich" in that term... audio and video still play in different ways in different browsers, and video is rarely able to be predictably integrated or controlled with other JS/HTML elements.
I'm still leaning towards "DHTML with independent data requests", although I've gotta agree that "AJAX" has a certain zing to it.... ;-)
jd/mm
8:17 PM
You might appreciate my "Zuggest" tool.
It uses the "Ajax" concepts you're talking about and works similarly to Google Suggest but searches against the Amazon Product database as you're typing.
Check it out: http://www.FrancisShanahan.com/zuggest.aspx
It's built with Javascript, Web Services, SOAP, XMLHttp, XML, C# and ASP.NET and SQL Server.
Would love to get some feedback on it.
-fs
8:37 AM
The question is whether the term "Ajax" will come to represent the general process of using asynchronous requests in the user's experience -- as opposed to its original specific-toolset meaning. Because right now it means both.
I hope that doesn't last. "I used Ajax to implement Ajax" is a statement destined for trouble. But I don't know what else to call the general process; even tying it to javascript is too limiting.
Over at Ajax Redux I'm trying to describe just the "Ajax design model" so we can abstract that puppy away from all the implementations that are drifting around.
5:03 PM
Post a Comment
Links to this post:
Create a Link
<< Home