Can rich Internet apps be web-friendly?

In my October 22 column, I argued that Gmail's aggressive use of dynamic HTML qualifies it as a kind of rich Internet application (RIA). As email correspondents and bloggers pointed out, the technique has a fairly long history. Many many wonder why it remains on the fringe. The reason, I think, is partly a weakness common to all RIA technologies. Whether it's based on DHTML, Java, Flash, .NET, or just a standard GUI, an RIA has a client/server architecture. Unlike a Web application which manages state information almost entirely on the server, though, an RIA achieves a more balanced distribution of that information between client and server. The benefits that flow from this arrangement can include responsiveness, context preservation, and offline capability. To achieve these benefits, though, we have to make some painful tradeoffs.


RIAs are protocol-driven. A programmer who masters an application's protocols can extend it or combine it with other applications. But there are no integration hooks available to the user. In a Web application, those hooks are simply URLs. Consider what happens when you include a MapQuest URL in an email to someone. A piece of state information -- namely, the state of the MapQuest viewer when displaying a given location -- has been reduced to a token that one person can hand to another. The same thing can usefully apply to the state of a shopping cart, or an airline reservation.


The idea that an application wears its state information on its sleeve, readily available for users to bookmark, modify, and trade, is an underappreciated strength of Web-based software. As the RIA bandwagon picks up steam, let's honor that idea and find a way to move it forward. [Full story at]

Over the past few weeks I've discussed this idea with folks at Macromedia and Laszlo. It's related to what Adam Bosworth has been saying recently:

The customers are, very literally, in control. Think of it as democracy versus totalitarianism. This last point showed up almost from day one in the web. The user interface customized itself to the users needs, location, and data in a dynamic way through the magic of dynamic page layout. Today, a full ten years later, most windows apps still don't do that. But heck they are only 2 or 3 or 4 generations evolved. Services, in the last decade, may have evolved 600 times by now all in reaction to what they have learned directly from customer use. [Adam Bosworth]
When Adam says "the user interface customizes itself," his language obscures a key point. Who does the customizing -- the developer or the user? I think the answer has to be: both. The web's rapid evolution is not merely the explosive result of zero-install dynamics. REST pours fuel on the fire. The web's architecture is compositional. When you expose application state on the URL-line, to the maximum degree possible, users and developers become co-composers.

Flash needs to figure out how to enable this collaboration, fundamentally and pervasively. Likewise DHTML. Likewise Java, .NET, and all the first-generation GUIs.

Former URL: