OPINION
The Web Browser's Unfinished Basement

I'm willing to bet it's a relevant statistic of the software industry that somewhere, at any given time, some poor schmo's Web browser is crashing. It doesn't matter if you use Mozilla, iCab, the latest version of IE or some other hunk of code: Sooner or later you'll run across an errant page that brings the whole shining mess down upon itself. Browsers are still rather flaky pieces of software, perpetually sprouting features while what lies beneath remains a tottering mess.

Over the years, projects like Mozilla and Konqueror have organized the complex process of developing a modern Web browser, integrating the different teams that work on a browser's many components. But the results are still poor. No browser has the kind of failsafe architecture that characterizes many operating systems and database software packages.

That's a problem, because browsers and other Web-based technology are fast becoming the centerpiece of modern business applications. If the future of corporate computing is going to compute at all, a kind of Marshall Plan is necessary to make browsers truly reliable, starting now.

The End of Featuritis

It is true that Web browser development has improved from the days when Netscape and Microsoft (Nasdaq: MSFT) were locked in combat, but that is mostly because development of new features has slowed to a crawl. Whereas it once seemed that features were added on a weekly basis, it has taken several years for the current crop of browsers to get behind the idea that blocking pop-up windows is generally a good thing to do. Back in the day, on the other hand, you got the feeling Netscape executives didn't want to discuss the humongous, tangled ball of yarn they were creating when they introduced something like whiteboarding features.

These days, Mozilla, OmniWeb and other efforts have clear road maps with lots of disclosure about bug fixes, outstanding problems and the like. The great wars to define new formats, such as Dynamic HTML, are, blessedly, behind us. Feature introductions also seem less capricious and more like a conversation. Tabbed browsing, for example, is pervading browser after browser in a slow, relentless march toward a new, as-yet-undefined vision of what browsing is.

But where is reliability? None of these browsers yet has the kind of protected memory structure one might expect from a modern operating system. So when an errant Javascript confuses the browser, all those tabs of Web pages, not just the offending page, go down the tubes as the browser crashes. Nor do browsers have the ability to preserve user input in Web forms during crashes. Just spent half an hour writing a message in a Web-based e-mail program? It's history if you happened upon a page your browser couldn't swallow. Browsers cache Web pages, but they provide no infrastructure for recovering data temporarily buffered while you're filling out a form.

Reliability Is Job One

Instead of pursuing reliability, the various browsers seem enraptured by the quest to define what a browser is supposed to be. Mozilla's statement of branding says the program is sometimes only a browser of Web pages, sometimes a suite of applications and sometimes two separate programs -- a browser and an e-mail program. Konqueror is a file browser and a Web browser, a document viewer for PDF files and other content, and a spreadsheet previewer. And did I mention it's a dessert topping?

There's nothing wrong with this browser renaissance. The competition between the half-dozen most prominent browsers will be productive, but developers need to start talking about the enterprise features these programs need to be really reliable.

The stakes are high. With the advent of .NET services, Java distributed applications and other Web services programs, browser technologies are becoming the platform for the next wave of software development. The day is coming when Web browsers will support true mission-critical programs. For the classic so-called "three-tier" Web program, much of the reliability will be buried in tiers two and three -- the Web server and the back-end content store or database. But that doesn't exempt the client, the browser itself.

As virtual runtime environments, such as the Java virtual machine and the .NET environment, become key pieces of infrastructure, issues of multithreaded operation, protected memory and user state management all deserve new attention. If the present level of reliability endures, Web services will never get off the ground.

Working on It

Fortunately, browser developers have been grappling with these issues for a while and seem genuinely intent on providing solutions. The improved performance and code simplicity of the Mozilla project's Phoenix browser are welcome signs of things to come. Mozilla developers also have sweated over individual issues, such as how to restore user session state after a browser crash. And some browsers, such as Opera, have moved even farther toward solving some of these issues.

The desktop browser wars are thankfully behind us. Technologies developed through standards bodies are the driving force now, rather than arbitrary agglomerations of features. Programming standards, such as XML, RDF, SOAP and the entire Web toolkit, have ensured a level playing field for developers. It's time to seize this enlightened moment to focus on the unfinished basement of the Web browser.