What Drives the Browser ?

The browser wars aren't just about the feature-rich against the featureless, nor about open source software butting heads with Big Evil Corporation #22935. It's really the underlying technology — the browser engines — at war here: the way these browsers take the mess that is HTML code, and turn it into something pretty for us to see.

Why, though, does the browser engine suddenly matter? We're happy to compare programs on their features, because it's really the features we're using. Right? But there's more to the browser than the features. With a great browser engine comes the ability to take that engine everywhere: from Windows to Linux to the Mac to the mobile phone to the game console to the Magic Intertube-surfing Shoe. A classic example is WebKit, which started out as the wind beneath Safari's wings, but now powers Google Chrome, the Android web browser, the web browser for Symbian, Safari Mobile, and such obscure but well-loved browsers as OmniWeb and iCab.

The simplest engine

Let us consider a hypothetical browser engine whose only purpose is to take HTML and convert it into a displayed web page — none of these fancy JavaScript or CSS designs for this one. As it receives HTML code, it finds an opening tag — , for example — and recognizes that it needs to start spewing out bold text until it reaches the closing tag.

That, then, is what browser engines are supposed to do — whatever the HTML tag tells them to. If you're old enough to remember WordStar, it's the same concept — tell the program to start bolding text here, and stop there.

But if you do want that fancy JavaScript and CSS stuff, this approach doesn't work, because you want your document all ready and rendered first, so that you can use JavaScript programming to add some interactivity. And so came the Document Object Model.

Treat them like objects

Once JavaScript was born, the simple read-and-spew approach wouldn't do at all. JavaScript needs to take web pages and manipulate them, and the only way to do that is to turn an HTML document into a collection of objects. The document itself, in fact, is an object.

Now, instead of HTML turning into a stream of text, the browser turns an HTML page into a Document object, with all HTML elements within becoming child objects — paragraphs, forms, links and so on — creating a hierarchical tree of objects. This object-like representation is called the document object model (DOM), and it opens up a host of possibilities.

In object-oriented programming (OOP), objects are wonderful things. They are balls of programmatic clay, which can be molded and manipulated as the programmer sees fit. If, for example, browser developers decide that all forms should have a green halo around them, they can do that — the HTML code itself doesn't need to change. And now, pages can become less boring, too.

By implementing a DOM, browser developers gave web designers their greatest gift yet: the ability to separate design from content. Browsers could support CSS, which could manipulate all the non-interactive properties of the HTML elements — color, size, font, borders — all the stuff it would be pointless to have JavaScript do.

And so, the foundation for the browser engine is complete. Simple, really.

The muddy pool

In an ideal world, Netscape and Microsoft would have implemented the DOM and JavaScript in the same way in both their browsers. The browser wars would have then centered around only features, and we wouldn't suffer the agony of sites that don't used web standards. Ah, well.

It all probably started with JScript, IE's JavaScript me-too. While it could understand some of Netscape's JavaScript, no other browser could understand JScript. Both companies came up with their own custom additions to the DOM standard — Netscape came up with "layers", much like Photoshop's layers, which could be turned on and off using JavaScript; Microsoft, on the other hand, added the document. All object, which let JavaScript (or JScript) select any object in the document with a simple document. All["id"], rather than navigating through the object tree, which was what the W3C would have wanted it to do. Other, more frivolous things came, too. Netscape, likely playing a nasty practical joke on the world, introduced the <blink> tag, which made text, well, blink annoyingly. Microsoft threw the <marquee> tag at us, resulting in the less annoying side-scrolling text.

Perhaps the only good thing to come out of this rush to implement new features was IE's XMLHttpRequest object, which lay the foundation for the AJAX we all know and love. Besides that, though, the web essentially went to pot.

But you've lived through this first browser war, and you've seen browsers approach more standard DOM implementations.

So why bother?

With all the recent emphasis on web standards, we've (somewhat) come beyond the days when different DOM implementations caused sites to run fine in one browser, and completely crash in another. As a user, there's little likelihood that you'll run into major problems.

Today's browser wars still centre around which features the engines can offer, but rather than coming up with their own non-standard features, the developers now race to implement features from the latest W3C standards.

This, however, doesn't mean that browser engines are becoming homogenous.

Behind the best

Perhaps the most important rivalry between browser engines is that of WebKit — which powers Safari, Chrome, and others — and Gecko, which powers Firefox.

WebKit is a fork of KHTML, which was designed to be a simple, light HTML engine that was standards compliant, and easy to maintain. It's been praised for its clean code and small memory footprint, both of which played key roles in what WebKit has become today — the browsing engine that can hop platforms really, really easily. WebKit is now the engine behind Safari on the iPhone, the S60 web browser on Nokia mobile phones, Android's web browser, and Google's Chrome. Developers are also using WebKit with the GTK (GIMP Toolkit) to develop rich internet applications in Linux.

Gecko, on the other hand, is so much more than just a simple HTML engine. It gives us the XML User Interface Language (XUL), which gives developers a way to write full-featured applications using simple XML, CSS and JavaScript. It makes Firefox extensions possible, and we all know how appealing those extensions are to Firefox users. XUL also became the base for applications such as Thunderbird, Songbird, and the Komodo IDE. To Gecko's disadvantage, these features made the code bulky and complex, making it difficult for it to make the transition into the mobile world. After much toil, Mozilla's Gecko-based mobile browser — Fennec — is in beta (as of this writing), and has been well-received.

Keeping the engine running

It’s simple economics, really: as customers, the ideal number of competitors we need is two, so that we can pit one against the other, and force them to offer us something better. WebKit may include better support for extensions, for example. We've already seen Gecko get speedier and lighter in response to competition from WebKit. If one browser engine were to dominate all our platforms, we'd just go back to the days of IE6 — innovation would stop, and every flaw in the engine would become painfully apparent on every platform, with no alternative in sight until the developers fixed it.

WebKit gives us rich internet applications as an added bonus, and Gecko gives us the ability to build desktop applications. Soon, we'll see more from both camps. This is good. This will do.