Why Mozilla matters

The browser is dead. It's gone to meet its maker, shuffled off its mortal coil, and joined the bleedin' choir invisible. Macromedia knows this. Microsoft knows this. The makers of countless variations on the theme of the next-generation rich Internet client know this. Everyone knows this except the folks who build and deploy Internet apps. We surveyed them recently, and they told us last-century Web apps are not only alive and kicking, but dominant. Is that nostalgia, or a leading indicator? Both, I suspect.

The pros and cons of the browser's always-connected page-refresh model are well-understood. Zero-footprint, cross-platform ubiquity is the upside, a clumsy UI tied to a Net umbilical cord is the downside. Among the current crop of proposed alternatives, Flash seems most compelling. It scores high marks for ubiquity, can render business information in powerfully interactive ways, and has a passable mechanism for working offline with local data. Flash still has to prove itself as a tool for business presentation, not just for multimedia eye candy, but I'm convinced that it can. Information displays that are densely populated with live data are the sweet spot for Flash; the management console of The Mind Electric's forthcoming "services fabric," Gaia, is a great example.

Flash's greatest weakness, though, is the browser's greatest strength. The browser is an engine for displaying -- and interacting with -- structured documents. The mission of Flash was always to complement the browser, not compete with it. That remains a proper division of labor. But our notion of what documents are is changing, thanks to Web services. Tear open the envelope of a SOAP packet, and you'll find an XML document inside. That document, representing a business transaction in flight, lives in two worlds at the same time. To applications and services, it's an XML payload. To people, it's a document to read, annotate, and pass around. Given the novel convergence of these two modes, the browser's future as an all-purpose Internet client may be brighter than we think.

Consider Microsoft's InfoPath. It's not built into IE (Internet Explorer) but it's built like IE, relying on the same XML parser, schema processor, XSLT transformer, DOM, CSS renderer, and script engine. InfoPath can receive XML payloads from a Web services network, and inject payloads back into the network, but the data users work with is displayed, updated, and validated locally. Microsoft hasn't chosen to reposition its browser for these purposes, but Microsoft's browser isn't the only game in town.

The truth is, I never use IE any more. On Windows, Mac OS, and Linux, my weapon of choice is Mozilla Firebird. In fact, both IE and Mozilla can do more sophisticated things than many people realize. My Weblog has a search feature, for example, that works by pulling XML content into the browser, querying it locally using XPath, and dynamically updating a rich results display. But while IE and Mozilla can both perform this magic, Mozilla has some other tricks up its sleeve. One I've been exploring lately is the DOM Level 2 Traversal and Range API, which Mozilla supports but IE doesn't. This API enables live interaction with fragments of XML documents. It's still just a raw capability not wrapped in any product vision. InfoPath needn't yet be glancing over its shoulder. But as Web services redefine documents, Mozilla, an open and extensible document-handling engine, looks more strategic than ever.