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
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.
Treat them like objects
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.
And so, the foundation for the browser engine is complete. Simple, really.
The muddy pool
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.
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.