The New Browser Wars: Chrome vs. IE vs. Firefox

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Just when you thought the browser wars were long-dead, they’ve roared back to life in a totally new incarnation. At stake this time is nothing less than the future of the way many of us work, now that the Web is an “application” and not just a place to read static pages.

The new wave of browsers — Firefox 4, Internet Explorer 9, Google Chrome (in just about all its incarnations) — all compete with each other fiercely to be the best possible delivery mechanism for the web as an app platform, in four basic areas:

Security
Speed
Reliability
HTML 5
RELATED NEWS AND ANALYSIS

Security

A more secure browser isn’t just a good idea. With each passing month, the number of ways browsers can be exploited rises, and the amount of damage that can be done with trivial exploits rises as well. A recent WhiteHat Security webinar, Breaking Browsers: Hacking Auto-Complete, demonstrated how a site could steal passwords out of FireFox’s Password Manager with nothing but simple JavaScript. It’s all the more troubling to hear about, especially as the browser becomes more a platform unto itself and less of a “mere” application.

It’s not as if progress hasn’t been made. The long-maligned Internet Explorer got a major security boost in IE 8, and Chrome has over time added its own crop of relevant security measures.

But future editions of browsers need to address security proactively, not reactively. The more of our work — and not just commerce — we trust to these applications, the more we should demand they be secure, and be audited in ways that reflect our browsing habits.

Some of the changes being made aren’t to browsers themselves, but to the behavior of existing protocols. Example: Mozilla’s also trying to advance the Content Security Policy, a set of controls that allow site admins to whitelist or blacklist sources for content. It’s easy enough for other browser vendors to add support for it—but that doesn’t mean they will, and it still falls to site maintainers to add support for it as well. Consequently, CSP (and other approaches of its kind) is limited in its usefulness until it becomes more than just a Mozilla-centric concept.

Speed

Discussions of a browser’s performance often boil down to how fast it can show a web page, but that’s not the whole picture. Because we spend so much time with a browser, the performance of the application as a whole has become crucial.

This explains why so many heads turned when, for instance, the original version of Firefox came out—and later, Google Chrome. It wasn’t just that they were fast at rendering pages; they were fast at everything—starting up, shutting down, suggesting sites in the address bar as you typed there, navigating between tabs, you name it.

This particular race has gone more to Chrome than Firefox as of late. Firefox may be working on striking features such as multi-tab functionality, but little of that will matter if the application as a whole lags incessantly. The browser that works best as a whole application—not just a pretty picture frame for a web page—will be the one both users and developers will be happiest to get behind.

Reliability

The more time anyone spends with a given application, the more reliable it has to be. People aren’t going to tolerate an app that crashes daily; they’ll ditch it and look for a substitute.

With browsers, there’s a lot less end-user friction to move from one browser to another (it’s not like they cost anything!), and so a browser that’s even slightly less stable than its competition is going to lose user share.

Each browser has their own implementation of this: IE has had process isolation for each tab since version 8; Chrome has had it since the beginning. Firefox does run plugins (e.g., Flash) in an isolated process for stability, and it almost never crashes during the course of regular browsing, but a single stuck tab can still bring down the whole application.

HTML 5

The next major revision of the protocol that powers the web is stuffed with features that promise to make the web that more of an application platform: client-side storage, advanced graphics rendering (Canvas), native in-browser support for video formats without plugins, and many other things.

The key word is “promise.” Delivering on that promise hasn’t been easy. Existing web applications have to be rewritten to use HTML 5, which is no easy feat by itself and means HTML 5’s biggest benefits won’t show up for a while.

Video in particular has been a thorny tangle of legal issues over what video codecs to support natively, with each browser picking a different approach and the HTML 5 spec not officially supporting any one of them.

And finally, there’s support from the browsers themselves. Many betas and technology previews (and even a few release versions) of existing browsers already support implementations of HTML 5, but the biggest burden for supporting HTML 5 falls to websites … and there are a great many more people creating websites than there are creating browsers.

At its heart, the new browser war is about how apps are gradually moving off the PC and out into the networked world—the browser, the cloud, that whole farrago of buzzwords that compel many of us to automatically roll our eyes when we hear them. It’s not likely that every desktop app can, or should, be replaced with an in-the-cloud, through-the-browser substitute. But the most basic and ubiquitous functionality already is, and the browser that can deliver those things most reliably and successfully will pave the way towards even more ambitious things.