A decade ago, the browser exploded many of our assumptions about building and deploying software. We were shocked to discover that less was more and that worse was better.
We've yet to fully absorb the lessons that the browser and the Web can teach us. Now, as the on-demand trend heats up and the pendulum swings back toward the GUI -- in the form of RIAs (rich Internet applications) -- it's vital to understand the strengths and weaknesses of Web-style software, and to assess its real potential.
...
The browser's Achilles' heel isn't merely its lack of support for advanced graphics. What really hampers developers and hurts users is the difficulty of managing complex interaction on the client. Dynamic HTML can minimize server round-trips and page refreshes, and applications such as Google's Gmail have shown this approach to be more capable than you might think. But DHTML has its limits.
We clearly need more advanced widgetry to help us deal with a range of data types and to guide us through sophisticated interaction scenarios. In some cases, this machinery will be deployed using one or another flavor of pure RIA. Hitting the sweet spot will require hybrid applications that leverage the simplicity, familiarity, and general-purpose utility of the browser, while using RIA technologies selectively where they can deliver the most bang for the buck. [Full story at InfoWorld.com]
This brief sidebar is part of InfoWorld's current cover story by Eric Knorr on the evolving nature of hosted applications. (There's also an interview with Marc Benioff of Salesforce.com and Halsey Minor of Grand Central.)
Responding to my sidebar, Ian Emmons made two observations:
- Any worthwhile UI is stateful. In fact, it isn't too far from the mark to say that the value of a UI is directly proportional to its statefulness. And yet we insist on building such interfaces on a fundamentally stateless protocol. Stateless protocols have wonderful technical properties, but the fact remains that the real world is stateful, and until we have a web protocol that recognizes this, web-based interfaces will be hobbled.
- The programming model for web-based interfaces is one of ridiculous complexity. Every aspect of a web-based UI is coded in a different language against a different API, and none of these layers interact in a well-designed fashion. Consider:
- Display uses HTML.
- Interaction logic is split across the network between JavaScript-against-DHTML and a server-side scripting environment. In addition, the server-side script literally generates the client-side JavaScript code, in spite of the fact that self-modifying code was long ago shown to be a technique fraught with peril.
- Business logic is often written in yet another language.
I entirely agree with the first point. Advanced widgetry alone will not save the day. We'll also need an intelligent cache -- along the lines of what the Alchemy project aimed to be.
On the second point, I'm not so sure. Virtually all interesting applications nowadays are composites made of local and remote services. Programming languages vary, as do APIs, but the services-oriented model abstracts away from these things. Is it complex? Sure. We've yet to figure out the tools, frameworks, and best practices we'll need for this emerging network of loosely-coupled message-driven services. But the power of that network being what it is, we're driven to find a way, and I suspect that we will.
Former URL: http://weblog.infoworld.com/udell/2004/12/03.html#a1126