Can the browser meet the demands of on-demand? On-demand apps are by definition Web apps. That won't come as a shock to enterprises because most of the latest internally deployed enterprise apps -- besides a few client/server holdouts -- already rely on the browser to deliver user experience.

But where is the Web app headed? 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.

Macromedia, Microsoft, and Sun Microsystems don't exactly welcome that analysis. Each owns a client platform -- Flash, Windows/.Net, Java -- through which it hopes to control the delivery of software as a service. But nobody owns or can own the ascendant browser, Mozilla's Firefox. ActiveX dependencies and inertia rule it out as an immediate substitute for Internet Explorer, especially in many corporate settings. But Firefox will gradually pry open the door. Now that there's a viable open source alternative to Internet Explorer, enterprises burned by vendor lock-in would be ill-advised to ditch the browser for a proprietary client technology. And of course, they won't.

The question is, How does one selectively and strategically enrich the browser?

This isn't a new problem. Almost from the start, we've augmented core features with plug-ins that handle foreign data types such as PDF, multimedia, and vector graphics. And we've married it to run-time engines such as Java and Flash. But the integration of these technologies into the browser has been on ice for years. Hardly anybody now remembers that LiveConnect, which enables two-way communication between JavaScript and Java applets, is still supported in the major browsers. The Netscape plug-in API is likewise widely supported but frozen in 1996.

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.