Chapter 6: The Browser Wars: From Mosaic to Chromium and Back

In November 1993, the National Center for Supercomputing Applications at the University of Illinois released the 1.0 version of a program called Mosaic. By that point, several web browsers already existed. Tim Berners-Lee had written one — WorldWideWeb, on a NeXT workstation at CERN in 1990. Others had appeared in academic settings in the years since. Mosaic was different in two ways that turned out to matter.

It shipped for the platforms most people actually had — Windows, Mac, and Unix, all at once, all from the same small team led by Marc Andreessen (then a 22-year-old undergraduate) and Eric Bina (a research staff member). And it had inline images, a graphical interface designed for people who hadn’t used hypertext before, and an install that was a download and a double-click rather than a research-lab artifact.

Within a year, Mosaic was the way most people experienced the World Wide Web. Andreessen left NCSA in early 1994 and, with Jim Clark (the former Silicon Graphics CEO), founded Mosaic Communications Corporation. The University of Illinois objected to the name. By the end of the year the company was Netscape Communications, the browser was Netscape Navigator, and the commercial web was in motion.

Mosaic established a pattern the rest of this chapter is the story of. The browser is the platform, and who builds the platform is a question with thirty years of consequences.

The First Browser War

Netscape Navigator dominated the consumer browser market through 1995 and most of 1996. At its peak, Netscape’s share of the web was above 80%. The company went public in August 1995 in one of the era’s most consequential IPOs — a profitless software company traded at near-unicorn valuations, opening the dot-com boom that would shape the rest of the decade.

Microsoft, for the first year of this, was behind. Internet Explorer 1.0 shipped in August 1995, late and unimpressive, as a bundled component of the Plus! pack for Windows 95. IE 2 followed three months later. IE 3, in 1996, was the first version that was competitive on technical merit. By IE 4 in 1997, Microsoft had effectively caught Netscape on rendering, on JavaScript performance, and on the kinds of features (CSS support, ActiveX, dynamic HTML) that web developers were starting to use.

The fight stopped being about technology. Microsoft bundled Internet Explorer with Windows. Computer manufacturers who shipped Windows shipped IE by default. The marginal cost to a Windows user of using IE was zero, and Netscape — which sold its browser as a downloadable product — couldn’t compete with free, pre-installed software shipped on most of the world’s PCs.

By 1998, Netscape’s market share was collapsing. The company released the Mozilla source code under an open-source license that year in an attempt to outflank Microsoft’s bundling advantage. AOL acquired Netscape in March 1999 for $4.2 billion. By 2000, Internet Explorer had over 90% of the browser market.

The United States v. Microsoft antitrust case, filed in 1998 and decided in 2001, found that Microsoft had used its Windows monopoly to leverage IE’s position. The remedy proposed by the district court — breaking Microsoft into two companies — was overturned on appeal. The final settlement required behavioral changes to Microsoft’s bundling practices but left the company intact and IE’s market position essentially unaffected.

Netscape, as a commercial entity, was finished. Mozilla, as the open-source project that emerged from Netscape’s code release, was just beginning.

The IE6 Stall

Internet Explorer 6 shipped in August 2001. For the next five years, Microsoft did almost no further work on it.

This wasn’t strategic neglect. From Microsoft’s perspective, the browser war had been won. The future of the operating system on every computer in the world was Windows, the future of the web browser on every Windows machine was Internet Explorer, and the team responsible for IE could be redeployed to other priorities. The IE development team was effectively dissolved between 2001 and 2003. The browser shipped with the operating system, updated rarely, and was treated by Microsoft as a maintenance item rather than a product.

The web didn’t stop. Web developers in 2001 had a browser with reasonable CSS support, decent JavaScript performance for the era, a working DOM, and basic XML capabilities. The web in 2006 had a browser with the same CSS support, the same JavaScript performance, the same DOM, and the same bugs. The platform had frozen. New ideas — better selectors, real font support, faster scripting, richer media — had nowhere to land. A developer who shipped a feature using a newer technique had to either degrade for IE6 (which meant most of their users) or skip the technique entirely.

Plenty of teams chose the second path. The IE6 stall is one of the reasons the plugin era described in the next chapter happened the way it did. Flash and Java applets offered consistent runtimes that the dominant browser couldn’t.

The IE6 stall is the cleanest case study in what monoculture costs a platform. The cost isn’t malice. It’s gravity. A dominant vendor with no competitive pressure has no urgency. Engineering teams are finite and other priorities exist. The platform stops moving because nothing makes it move.

The lesson generalizes. Anyone who has worked on a software stack with a near-monopolist vendor in any layer — the JVM in the early 2010s, the JavaScript ecosystem during certain bundler hegemonies, the public cloud market today — has seen the same dynamic at smaller scale.

Firefox and the Gecko Renaissance

The Mozilla open-source project, started by Netscape in 1998 as a way to keep its codebase alive after the company’s collapse, spent its first several years on an ambitious but unwieldy product: the Mozilla Application Suite. The suite included a browser, an email client, an HTML editor, and a chat client, all on a shared engine. The browser inside the suite was capable but slow, complicated, and aimed at a different audience than the one IE6 was failing.

In 2002, two Mozilla developers, Dave Hyatt and Blake Ross, started a side project to extract a leaner, browser-only product from the codebase. It was originally called Phoenix, then Firebird (after a trademark complaint from the Phoenix BIOS vendor), then Firefox (after another trademark complaint from the Firebird database project). Firefox 1.0 shipped in November 2004.

Firefox was a credible alternative to IE6 from day one. It had tabs (IE6 didn’t). It had a popup blocker (IE6 didn’t, by default). It had an extension system that turned the browser into a platform for community-built features. Its rendering engine, Gecko, was actively developed in a way IE6’s Trident wasn’t. And it was open source — built by a foundation rather than a corporation, funded initially by Google in a search-deal arrangement that gave Mozilla a viable business model without making it a Google subsidiary.

Firefox’s growth was steady and unspectacular until it became impossible to ignore. By 2008, Firefox had crossed 20% global market share. Microsoft re-formed the Internet Explorer team in 2006 and shipped IE7. The IE6 stall ended because a competitor existed again.

Mitchell Baker, who had been general counsel at Netscape and became Mozilla’s leader through the transition, has been the through-line of the project’s institutional continuity. Brendan Eich — JavaScript’s author, met in the previous chapter — co-founded Mozilla in 1998 and served as CTO and briefly as CEO. The organization they built has been one of the most important counterweights to monoculture the web has ever had. It still is, even as Firefox’s market share has fallen well below its 2010 peak.

WebKit, Blink, and the KDE Inheritance

In 2003, Apple shipped Safari 1.0. The decision to build a browser at all wasn’t obvious — Apple had been shipping Internet Explorer for Mac (built by a separate Microsoft team) as the default browser for years. The decision to build its own engine was less obvious still. The web rendering problem was hard, the existing options (Gecko, Trident) were either too tied to other products or commercially unavailable, and starting from scratch would have meant years of engineering before reaching feature parity.

Apple found a third option. KHTML was an open-source HTML rendering engine that had been developed by the KDE project on Linux since 1998, primarily by a German developer named Lars Knoll. KHTML was small, fast, standards-focused, and BSD-licensed. Don Melton, the engineer Apple assigned to the browser project, recognized that KHTML was the substrate that made the schedule possible. Apple forked KHTML into WebKit and shipped Safari on the timeline a typical Apple product launch demanded.

The KDE-to-WebKit chain is one of open source’s clearest examples of what unglamorous, mostly-volunteer infrastructure can become. Lars Knoll and the small group of KHTML maintainers worked for years on a renderer that almost nobody outside KDE used. Apple’s adoption made it the foundation of one of the largest software products in the world. It would later become the foundation of an even larger one.

In September 2008, Google launched Chrome. Chrome’s rendering engine was WebKit. Its JavaScript engine, V8, was a from-scratch design by a team led by Lars Bak — a Danish engineer who had previously worked on the Beta JVM, the Self language runtime, and Sun’s HotSpot. V8 was significantly faster than the JavaScript engines shipping in other browsers at the time, and the gap forced the rest of the industry to take JS performance seriously. SpiderMonkey at Mozilla and JavaScriptCore at Apple both received major rewrites in V8’s wake.

In 2013, Google forked WebKit into Blink. The fork was contentious — Apple and Google had been collaborating on WebKit for nearly a decade, and the split meant two engines diverging from a common ancestor. The reasons were mostly governance and architectural: WebKit’s project structure had become unwieldy for a project the size Chrome had grown to, and Google wanted more autonomy over the rendering pipeline. Blink is what powers Chrome today. WebKit is what powers Safari. Both descend from Lars Knoll’s KDE work in the late 1990s.

The Current Near-Monoculture

Today there are three rendering engines in widespread use: Blink (Google), WebKit (Apple), and Gecko (Mozilla). Two of them descend from the same KHTML codebase. One of them — Gecko — is the lone independent.

The market share is more concentrated than the engine count suggests. Chrome, Edge, Opera, Brave, Vivaldi, Arc, and the Chromium-based versions of countless smaller browsers all use Blink. Together they account for roughly 70% of global browser usage. WebKit powers Safari on macOS and is the only engine permitted on iOS — Apple’s App Store policies require every browser on iPhone and iPad to use WebKit as its rendering engine, even when the browser brands itself as Chrome or Firefox. This makes WebKit’s share roughly the share of iOS traffic on the web, which is significant. Firefox, the only major browser with a non-Blink, non-WebKit engine, sits below 5% global share.

The European Union’s Digital Markets Act, which entered enforcement in 2024, requires Apple to allow alternative browser engines on iOS within the EU. The first non-WebKit browsers on iOS have begun to appear during 2025. It’s too early to tell what their adoption will be. The policy intervention is interesting on its own terms — regulators have explicitly named browser engine diversity as a public-interest concern.

Whether this is a monoculture in the worst sense is debatable. Apple’s WebKit and Google’s Blink, despite their shared origin, have diverged significantly over twelve years and now disagree on many implementation details. Firefox is small but well-resourced enough to remain a credible standards participant. The IE6 dynamic — one vendor with no incentive to move — doesn’t apply.

What does apply is a different concern. The three remaining engine teams are inside three of the largest companies in the world, and each of those companies has product strategies that the browser serves. Chrome’s incentives are Google’s incentives. Safari’s are Apple’s. Firefox’s are Mozilla’s, which mostly means not Google’s or Apple’s, but the funding for Mozilla still flows largely from Google through the default-search-engine deal. The independence is real and it has a price.

Standards as the Counterweight

The reason this near-monoculture isn’t catastrophic is institutional.

The W3C (World Wide Web Consortium), founded by Tim Berners-Lee in 1994, is the original web standards organization. The WHATWG (Web Hypertext Application Technology Working Group), founded in 2004 by employees of Apple, Mozilla, and Opera in frustration with the pace of W3C’s XHTML work, is the body that now produces the living standards for HTML, DOM, and many of the platform’s other core specs. The two bodies have a complicated history and a now-collaborative working agreement, with WHATWG producing the spec text and the W3C reviewing and ratifying.

TC39, met in the previous chapter, handles JavaScript. The W3C’s working groups handle CSS (the CSS WG), accessibility (WAI), service workers, web payments, and dozens of other surface areas. Each one operates roughly like TC39 — open membership for member organizations, a structured proposal process, conformance test suites, and a strong rule against breaking what has already shipped.

The institutional output is a shared specification that all three engines target. The engines compete on performance, on developer tools, on platform integration. They cooperate on what the web is. Code that targets the spec runs on all of them, with the kind of compatibility margin that turns into the platform’s evergreen guarantee.

The Interop initiative is the most recent iteration of this. Beginning with Interop 2022 and continuing annually since, the major browser vendors agree publicly on a list of platform features where compatibility between engines is currently weakest, and commit to closing the gap in the coming year. The 2024 focus list included accessibility, declarative shadow DOM, popovers, scroll-driven animations, and modern CSS features. The 2025 focus is similar. Progress is tracked publicly on wpt.fyi and the results are measurable.

WinterCG (the Web-interoperable Runtimes Community Group) handles a parallel problem on the server side. The JavaScript runtimes — Node, Deno, Bun, Cloudflare Workers, Vercel Edge — are converging on a shared subset of web APIs so that code written for one runtime works on the others. The runtime story belongs to a later chapter. The standards-body shape is recognizably the same.

Standards work is institutional infrastructure. It is slow, dull, vital, and quietly responsible for most of what makes the web’s evergreen platform possible.

The Next Engines

Two recent projects are worth naming because they exist and because their existence is hopeful.

Servo started at Mozilla Research in 2012 as an experimental browser engine written in Rust. The project was initially aimed at exploring concurrent and parallel design choices that Gecko’s older C++ codebase made difficult. Rust as a language emerged in part from Servo’s requirements. Several of Servo’s design ideas have since been adopted back into Gecko. The project was paused at Mozilla in 2020 but moved to the Linux Foundation in 2023 and continues with a small, dedicated team.

Ladybird started in 2020 as a side project by Andreas Kling, the developer of the SerenityOS hobbyist operating system. Ladybird is a from-scratch browser engine with no shared lineage to WebKit, Gecko, or Blink — the first serious attempt at a fully independent engine since the 1990s. The project gained enough momentum that Kling left his job in 2024 to work on it full time, and the Ladybird Browser Initiative non-profit was formed with funding from a small group of donors including GitHub’s former CEO Chris Wanstrath. The goal is a 1.0 release in 2026 or 2027.

Neither project is going to take market share from Chrome any time soon. The point isn’t market share. The point is that engine diversity remains possible, and that the work of building a standards-conformant browser is enough of a known problem that small teams can attempt it. The spec text written by the W3C and the WHATWG is the spec text both projects target. If Ladybird ships a 1.0 in 2027, it will be a 1.0 of the web — the same web Chrome and Safari and Firefox are also implementing.

The standards bodies have made the web one platform implemented by three (or six, or eight) engines, instead of three parallel platforms loosely related to each other. The standardization story from the previous chapter and the engine story in this one are two halves of the same institutional accomplishment.

What the Engine Story Means for the Rest of the Book

The browser engine is the bottom of the application platform this book is about. Everything we’ll discuss in Part II — HTML semantics, the DOM, attributes, events, forms, CSS, accessibility — is interpretation. The engines do the interpreting. The standards bodies define what correct interpretation means. The committee work described in this chapter and the previous one is the reason any of this can be relied on at all.

The next several chapters return to the historical thread. The plugin era — Java applets, Flash, Silverlight — is the story of what developers and product teams tried before they trusted the platform to grow up. Then Ajax. Then jQuery. Then the structure libraries, the MVC frameworks, React, the meta-frameworks, the runtimes. Each one is a layer added because the platform underneath wasn’t enough, yet.

The premise of this book’s argument is that the platform is, finally, enough. The chapters that follow this one cover the layers we added before that became true. The chapters after them cover what the platform now actually is.

Exercise: Read a Test Report

The exercise for this chapter is to look at how engine differences show up in practice.

Visit wpt.fyi, the Web Platform Tests dashboard. The site shows the conformance status of every browser engine across the full WPT test suite, which covers virtually every web standard. The default view shows test pass rates across Chrome, Firefox, Safari, and Edge.

Pick a platform feature you’ve used recently — something specific, like <dialog>, container queries, :has(), popovers, or view transitions. Find the corresponding section in the test results and look at the cross-engine pass rates. Click through to a failing test in one of the engines. Read the test source. Read the bug report (the WPT issue tracker, or the engine’s own bug tracker, will usually be linked).

Then answer these:

1. What’s the specific behavior being tested? Is it a corner case, or something you’d hit in normal use?
2. Which engines pass? Which fails? What’s the underlying disagreement — a spec ambiguity, a missing implementation, or an intentional deviation?
3. Find the bug’s history. How long has it been open? Has it been triaged, prioritized, or sitting?
4. If you were shipping a product that depended on this feature, what would your fallback be? A polyfill, a feature detect, a different approach?
5. Is this feature on the current Interop focus list? If yes, what’s the expected resolution date? If no, why might it not be?

The goal is to develop a working sense of how engine differences actually surface — not as catastrophes but as a steady background of small disagreements that the standards bodies, the WPT suite, and the engine teams are continuously working to reduce. The web you build for is the result of that work.