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.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
