Javascript RIAs come of age

A recent article by Jesse James Garrett crystallizes what many in the Rich Internet Application developer community have been saying ever since the gmail beta: Javascript RIAs (which Garrett awkwardly attempts to brand as “AJAX”, for “Asynchronous JavaScript and XML”) seem to be finally coming of age. These techniques have been possible since at least 2002, but have been recently popularized by the never-ending stream of cool javascript RIAs from google (gmail, google suggest, google maps…).


The article’s attempt to brand the approach with a catchy acronym is unfortunate. I agree with saladwithsteve, who writes
“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.”
Nevertheless, the article is a nice introduction to XMLHttpRequest for non-technical audience (a better article for people who code is here.)
In my opinion, the discussion that has surrounded the article has been lacking a little perspective. It seems to me that Javascript RIAs have 3 fundamental pillars, and that to focus exclusively on XMLHttpRequest is to miss the point:
javascript_ria2.gif
1)Getting new data from the server without going reloading the user interface: XMLHttpRequest is, as Garrett writes, a key part of the puzzle, since it provides a transport mechanism for data to be fetched from the server without refreshing the page.
2)Animation: Using CSS to position screen elements allows the ability to do animation / drag-and-drop. Animations are particularly important for screen transitions.
3)Changing the user interface without going back to the server: The element.innerHTML attribute in JavaScript is writable. This allows JavaScript developers to write code that modifies the html displayed to the user without reloading the page. Without this, there would be no point to using XMLHttpRequest, because the data you fetched would have no way of getting into the presentation layer.
Taken together, these three little JavaScript features allow developers to achieve a level of interactivity not seen before in traditional web apps.
Discussion on Javascript RIAs continues on Slashdot and elsewhere in blogland.
The Javascript Rich Internet Application has come of age. But is it the right approach for the app you’re building? I’ll be continuing this discussion with a future post comparing Javascript RIAs to Flash RIAs. As always, feel free to comment below.

4 thoughts on “Javascript RIAs come of age

  1. John Dowdell February 27, 2005 / 8:06 pm

    Agreed… naming discussions are some of the heaviest discussions…. 😉
    I’ve been trying to speak of it with more of a functional definition, with phrases like “DHTML with separation of data requests from layout/logic requests”… that “DHTML” is a moniker, too, but most people know it means advanced JavaScript to change the visible UI, and the “separation of data and presentation” is also a familiar idea. The great thing now is that people are actually doing this in the real world, with browsers that a majority of the audience uses.
    Whether XML-HTTP or hidden frames, the key difference from classic DHTML is that ongoing data requests no longer require that the layout and local logic need to be refreshed as well. (I’d lean towards keeping “RIA” for richer presentations, and so far audio and video presentations still vary greatly across browsers and configs.)
    Maybe “data-independent DHTML” or such, how does this moniker seem to you…?
    Regards,
    John Dowdell
    Macromedia Support

  2. jon February 27, 2005 / 8:38 pm

    First, thanks for stopping by John!
    “Richer presentation” is a tough thing to pin down. I gather that what you’re saying is that google maps is an RIA, but google suggest isn’t. Is it when we move away from a form-centric UI that an app becomes an RIA?
    What about RIA’s that are essentially for data entry? If the broadmore hotel app didn’t have photographs of the rooms, would it still be an RIA? That seems illogical to me.
    “Data-independent DHTML” is too long and not sexy enough (although the alliteration is nice). We need some marketing guys to work on this for us. ;->

  3. John Dowdell February 28, 2005 / 10:55 pm

    “I gather that what you’re saying is that google maps is an RIA, but google suggest isn’t.”
    I’m not sure, I have a history of difficulties locking down where a label ends and begins…. 😉
    I do know that when Macromedia staff introduced that term “Rich Internet Application” in that half-meg PDF a few years ago, that promoting audio and video into first-class citizens integrated with text and live data was one of the key differentiators from a document-based approach:
    http://www.macromedia.com/devnet/mx/flash/whitepapers/richclient.pdf
    But since then that term “RIA” has become enormously popular, and I suspect each speaker redefines it in a slightly different way.
    I’m not sure I could convince others of what that label “should” mean, but I just know that, in light of its history, I’d feel a little strange at applying it to JavaScript applications where you couldn’t predict how audio or video would integrate with the rest. No biggie, that’s just me.
    ” “Data-independent DHTML” is too long and not sexy enough” Yeah, you’re right, AJAX it is then, with Comet and Mr. Clean to follow soon I guess…. 😉
    jd

Comments are closed.