Thirty years of browsers, three engines left and Ladybird

A small confession to start. A few months ago I moved to Zen, the browser built on Gecko, Firefox’s engine. Not for ideological reasons. It is simple: the interface gets out of the way, tabs are grouped into workspaces, one per project, and I finally manage to keep myself organised without an extension or a system of my own. No frills. It just fits the way I work.

That switch made me look around, and the view is strange. The browser is, by far, the most used application on a computer: Chrome alone is estimated at more than 3 billion users, Safari at more than a billion, and on desktop most of our screen time happens in a browser window. On mobile, apps win the clock, but a large part of them are WebViews, which is a browser without the address bar.

At the same time, without noticing, most of us develop with Chrome, because its DevTools are the best and because chrome://webrtc-internals has no real equivalent (Firefox’s about:webrtc comes closest, Safari has nothing comparable). And since this year, we do not even drive the browser by hand any more: Claude or Codex can open a page, read the console and click through a flow via MCP, first with the Chrome DevTools MCP server, and since July with Safari’s own MCP server shipped by the WebKit team.

And while the engines concentrate, the browsers multiply: Zen, Dia, Helium, Comet, Samsung Browser on Windows, each promising another experience, without Google, with an AI, inside another ecosystem. So the questions I wanted to answer are simple ones. What does this change for us, developers? And what is Ladybird, this newcomer that seems to want to start from zero?

Three wars, one winner

The history of browsers is told as a series of wars, and it is worth keeping in mind because the current situation is their direct result.

Desktop share: IE 95% in 2003, Firefox ~30% around 2010, Chrome 65% in September 2026 (StatCounter).

Nobody has fought Chrome since 2015. The fight is for second place, and on desktop Edge took it the day it switched to Chromium.

The war that never happened is the mobile one. Since 2007, Safari and Chrome have been installed by default on the two phones that matter, and the mobile market simply tracks the Android/iOS split: Chrome 67.6%, Safari 24.7%, everything else under 4%. And there is a fact that still surprises most developers I talk to, myself included until I checked: on an iPhone, Chrome, Firefox and Edge still run on WebKit today, everywhere in the world. They are Safari with another icon. Apple has required it since the early days of the App Store, and the two laws that broke the rule have not changed the reality yet.

The EU Digital Markets Act obligations apply since 7 March 2024; Apple complied with iOS 17.4, released two days earlier, by shipping BrowserEngineKit, which lets a browser use Blink or Gecko, but only in an app distributed solely in the EU, from a developer established in the EU, after committing to a long list of security and conformance requirements that Apple approves. Japan’s Mobile Software Competition Act added the same obligation on 18 December 2025. Nowhere else: in the US, in the UK (where the competition regulator is looking at it but has not ruled), in Switzerland, every iOS browser is still WebKit by App Store rule.

Two and a half years later, nobody has walked through the door. Google has had an experimental Blink-on-iOS port in Chromium’s tree since 2023 and has shipped nothing. Microsoft only showed a research prototype in June 2026, scoring 28.6% higher than Safari on Speedometer 3.1, to make a regulatory point.

And Firefox’s head, Ajit Varma, said out loud in an Ars Technica interview on 29 September 2026 that Mozilla will not build an EU-only Gecko version: maintaining two Firefox for iOS would basically double its iOS team, and Apple lists each browser only once in the App Store, which makes a regional engine switch a migration nightmare. Mozilla is asking Apple and regulators for one set of global rules instead.

Until that happens, iOS stays a WebKit monoculture by design, and that is the mobile war of the next two years: not between browsers, but between Apple and the regulators over whether the EU exception becomes the worldwide rule.

The families: three alive, a dozen dead, two unborn

Wikipedia’s list of notable web browsers has around 180 entries, past and present, and it still misses most of the recent ones (Dia, Comet, Helium…) and the countless Chromium reskins: the real number runs into the hundreds. Underneath them, three engines carry almost the whole web: Blink (Google), WebKit (Apple) and Gecko (Mozilla). Everything else is history (Trident, EdgeHTML, Presto, KHTML, the pre-iPhone mobile engines), under construction (LibWeb, Ladybird’s engine, and Servo, an engine made to be embedded in applications) or niches (Flow, NetSurf).

Igalia is a Spanish open-source consultancy, run as a worker-owned cooperative, and one of the biggest contributors to browser engines: it maintains the Linux ports of WebKit (WebKitGTK, WPE), implements web standards in Chromium and Gecko for its clients, and has been maintaining Servo since 2023.

Engine shares are my approximations from StatCounter (September 2026, all platforms), counting Chrome on iOS as WebKit. Browser counts come from Wikipedia’s list of notable web browsers (October 2026), which skips most recent and regional ones.

From a web page’s point of view, Chrome, Edge, Opera, Brave, Vivaldi and Samsung Internet are one engine with different settings. On an iPhone, Chrome and Firefox are Safari in disguise. Firefox and its forks, Zen included, are the only mainstream browsers that depend on neither Google’s nor Apple’s code. That is part of why my switch felt like a small vote.

Why so many new browsers, then?

Briefly, because the two halves of the market obey different economics. An engine is tens of millions of lines and several hundred engineers; Google pays for Blink with ads, Apple with the iPhone, Mozilla with Google’s default-search deal (75 to 85% of its revenue, depending on the year). Microsoft gave up EdgeHTML in 2020, Opera gave up Presto in 2013. A user interface on top of Chromium, on the other hand, costs a few weeks. The entry barrier is zero, the survival barrier is enormous.

What motivates the newcomers fits in four lines. The entry point: whoever holds the door to the web chooses the search engine and the assistant (Chrome for Google Search, Edge for Bing and Copilot, Atlas and Comet so that AI search would not go through Chrome). The ecosystem: Samsung, Huawei, Yandex, Naver only need to keep their customers inside their services. Privacy: Brave, DuckDuckGo, Tor, Helium, Zen exist because the platform browsers are also collection tools. Conviction: Ladybird and Pale Moon exist so that a web without Google or Apple remains possible.

And what it pays is sobering: the browser itself earns almost nothing. It earns for whoever sells what sits behind it. Google pays Apple about $20B a year to be Safari’s default search; Mozilla gets about $500M a year from the same source; Opera made about $615M in 2025, almost all of it from ads and search deals; Atlassian paid $610M in cash for The Browser Company, the maker of Arc and Dia; Zen and Helium live on donations, Ladybird on sponsors and donations. The recent casualties tell the same story: Arc (2025) and ChatGPT Atlas (shut down this August, less than a year after launch) died for lack of users willing to change habits, not for lack of quality.

So many browsers: is it getting harder to build for the web?

Hundreds of browsers on three engines, a new one every few months, and each of them a place where your app can break. You would expect building for the web to get harder every year. 2026 says the opposite: it was a great year for web developers. Agents changed the way we work: testing agents that run a flow on their own, MCP servers that let them drive a real browser, and pages that start to talk to them. Three things happened at once.

The agent drives the browser. With the Chrome DevTools MCP server, and since Safari 27 and Safari Technology Preview 247 with Apple’s own safaridriver --mcp, a coding agent can open a page, read console messages and network requests, take screenshots, evaluate JavaScript and click through a flow, then fix the code and try again, without me describing anything. Safari’s server, notably, has no access to your personal Safari data (AutoFill, browsing activity), which is a sensible default the Chromium equivalents do not all share. Mozilla has its own too, firefox-devtools-mcp, built on WebDriver BiDi.

The page talks to the agent. WebMCP, proposed by Google and Microsoft in a W3C community group, lets a site declare its own callable tools (document.modelContext.registerTool(...), it moved from navigator to document in May) so that an agent does not have to scrape the DOM. It shipped behind a flag in Chrome 146 and is in origin trial since Chrome 149. The other engines are not following: WebKit formally opposed it in June (security, privacy, API design), and Mozilla’s position is neutral. It is a Community Group draft, not a standard.

The agent becomes the browser. Dia, Comet, Opera Neon and the late Atlas tried to put the assistant at the centre. Atlas’s end is the most interesting signal of the year: OpenAI concluded people do not switch browsers for an agent, and put the browser inside ChatGPT instead, plus a Chrome extension. Chrome, meanwhile, simply put Gemini and AI Mode in the address bar.

The gains are real. I now get a Safari-specific layout bug reproduced, diagnosed and patched in one loop, on a machine where I rarely opened Safari. Cross-engine testing, the thing we all postpone, becomes cheap: the agent runs the same flow in three browsers and reports the differences.

Is it all rosy? No. Three caveats.

1. First, the agent tests what I ask; if I only point it at Chrome, I get Chrome-shaped code faster. The bias we already had is now automated.
2. Second, MCP servers are also an attack surface: a page can carry hidden instructions, and an agent with a real browser profile can leak it. Safari keeping its server away from your personal data is the right call; prompt injection through web content is the new XSS.
3. Third, WebMCP, if it succeeds, shifts the question from “does my app render in this engine?” to “does my app expose the right tools to this agent?”, and only one engine implements it so far. We are at risk of a second Chrome-only web, this time for agents.

Ladybird: the one that starts from zero

Ladybird is the only browser in this article aiming at the full modern web whose whole engine, HTML, CSS and JavaScript included, owes nothing to Blink, WebKit or Gecko (the Servo engine and the Flow browser both borrow Firefox’s SpiderMonkey for JavaScript).

Origin. It began in 2019 as the HTML viewer of SerenityOS, the hobby operating system Andreas Kling started as a personal project after rehab, written entirely from scratch as a matter of principle. The viewer grew into LibWeb, got a name in 2022, and in June 2024 Kling forked it out of SerenityOS. In July 2024 he and GitHub co-founder Chris Wanstrath announced the Ladybird Browser Initiative, a 501(c)(3) non-profit backed by a $1M pledge from Wanstrath’s family, and a charter that matters: no default-search deal, no user monetisation, ever. The exact model that funds Firefox is the one Ladybird refuses.

Architecture. Multi-process from day one, Chrome-style: a UI process, one sandboxed WebContent process per tab, an ImageDecoder process and a RequestServer process, so that image decoding and networking happen outside the process running the page, plus newer service processes for audio, video decoding and compositing. The core bricks are home-grown: LibWeb (HTML, CSS, DOM, layout), LibJS (97.8% of the test262 subtests imported into WPT in April 2026), LibWasm, LibGfx, LibMedia, LibIPC. The code is C++, and since February 2026 it is moving to Rust: first the JavaScript parser and bytecode generator, now parts of LibWeb, LibWasm and others, after the 2024 idea of moving to Swift was dropped. Ladybird does use third-party libraries, via vcpkg: Skia, HarfBuzz, FFmpeg, ICU, and also curl for HTTP and OpenSSL for TLS. The rule is narrower than “no dependencies”: no code from any other browser engine.

Where it stands after two years as a standalone project. More than 2.1 million Web Platform Tests subtests passing in September 2026, after crossing 2 million in March. Alpha targeted for 2026 on Linux and macOS, “a daily driver for developers and early adopters”; beta in 2027; stable in 2028. Windows later, mobile not a current focus. In June 2026 the project stopped accepting outside pull requests: only maintainers submit code now, for a clearer security model before the alpha, and because AI makes plausible-looking patches cheap to produce. Sponsors include Shopify, Cloudflare, FUTO, Proton and the Human Rights Foundation. Simple sites render well; many complex web apps do not yet. It is pre-alpha software you still build yourself.

And WebRTC, libwebrtc or not? This is the part I was most curious about, because WebRTC is one of the last big construction sites, and it started this summer. On 9 September 2026, maintainer Ali Mohammad Pur merged “most of the audio stuff needed to get webrtc working” (PR #11209): microphone capture through PulseAudio and Core Audio, a getUserMedia() that returns real audio tracks through MediaStreamTrack (the LibWeb/MediaCapture module arrived in February), MediaStreamAudioSourceNode and MediaStreamAudioDestinationNode, a working AnalyserNode, AudioWorklet.addModule(), and an audio pipe between the render thread and the main thread.

He mentions testing against Krisp, the noise-cancellation technology many conferencing apps embed, and that the code was extracted from his “webrtc branch”, which is not merged yet.

Does that branch wrap libwebrtc? Nobody knows yet: RTCPeerConnection is not in the main branch and the branch is not documented. Ladybird has two choices.

Take libwebrtc. The charter does not forbid it: it is a Google library, not a rendering engine, like FFmpeg or Skia. It is the path Safari and Firefox took, and the project is pragmatic: it replaced its own TLS with OpenSSL and its HTTP stack with curl when that was the safer choice. libwebrtc is a much bigger beast, built with Chromium’s own tooling and bringing its own threads and codecs. But it also brings years of real-world interoperability, congestion control and echo cancellation, maintained by Google.

Write its own. A home-grown stack (ICE, DTLS, SRTP, SCTP) on top of LibMedia, FFmpeg and OpenSSL, the way Pion did in Go or str0m in Rust. Years of work, and every interoperability bug to find again, one conferencing service at a time.

The simplest and least risky choice is libwebrtc, technically. The risk is elsewhere: drifting from its own ideology, with Google code at the heart of the one feature that matters most to us. Unless… a team that wrote its own JavaScript engine, CSS engine and Wasm runtime from scratch rarely picks the simplest path. Starting with the audio graph and getUserMedia rather than with a PeerConnection wrapper is a hint, nothing more.

If Ladybird does write its own, it will be the only WebRTC stack in a browser meant for everyday use that is not built on Google’s libwebrtc, which runs Chrome and Safari and much of Firefox’s media pipeline. Servo, the other new engine, only has an experimental WebRTC behind a preference, built on GStreamer.

Where this leaves us

Can Ladybird find a place? As a mass-market browser, almost certainly not before 2030, and maybe never; nobody has taken share from a preinstalled browser in fifteen years. The only one that climbed in that time is Edge, now second on Windows behind Chrome. But Edge is the preinstalled browser: it ships with every Windows PC, opens your PDFs and comes back after every update. Taking second place that way requires owning the operating system, which helps when you are Microsoft. 🙂 Ladybird has none of that. As an engine, yes, and that is what matters: a fourth independent implementation of the web platform is a check on the other three, the way Firefox at 3% is still the only major browser where full ad blocking works since Chrome dropped Manifest V2 in 2025. If a non-profit ships a working alpha in 2026 and a WebRTC stack after that, it will have proved that building a browser is still possible outside a trillion-dollar company. That alone changes the conversation.

Will Gecko resist? Three percent is survivable for an engine funded by a competitor’s cheque, as long as the cheque arrives, and the Google antitrust remedies left the search deals in place, as long as they are not exclusive. But Firefox cannot win by being a cheaper Chrome. Its differentiation is already visible in the forks: Zen, LibreWolf, Tor, Mullvad are Gecko because Gecko is the engine that is not controlled by an ad company or a phone maker. Full ad-blocking after Manifest V2, containers, no telemetry by default, and, the day Apple or the regulators offer one set of global rules, being the first non-Apple engine on iPhone, since Google clearly does not want to be. Mozilla should sell independence as a feature, and let the forks do the interface work, which they do better.

Are browsers living their last days? Elon Musk said on Joe Rogan’s podcast that in five or six years there will be no apps and no operating system, only a device that “anticipates” and generates what you want through AI, and in July he answered “True” to a post claiming that browsers, websites and most software will fade away as people rely on AI agents.

I have heard this before. Apps were going to kill the web in 2010; voice assistants were going to kill screens in 2016; the metaverse was going to kill everything in 2021. Each time, the browser absorbed the new thing instead of dying from it, because it is the one runtime that belongs to nobody. The first AI-native browser, Atlas, is already dead, and the agents that replaced it drive Chrome and Safari through MCP: the browser is not disappearing, it is becoming the agent’s hands. On the other hand, AI is eating the content: assistants answer from pages they have read for us, and we no longer open those pages. (Maybe you are not even reading this page yourself, and Claude is reading it for you. 🙂) If that becomes the norm, the browser as an interface, the window we look at the web through, may one day become obsolete, or be rendered differently: a generated answer, a voice, a card inside a chat, with the page underneath read only by the machine.

We have seen reversals of fortune in this market, IE at 95% then dead, Firefox at 30% then 3%, Chrome from nothing to 65%; the next one may be that the most used application is no longer the one you look at, but the one your assistant uses on your behalf. That is still a browser. And whichever engine it runs on, it had better speak WebRTC.

As for me, I am staying on Zen. And I have a Ladybird build directory on my laptop, waiting for that webrtc branch. 🙂

Sources

• Market share: StatCounter Global Stats (September 2026)
• Wikipedia, Usage share of web browsers
• Wikipedia, List of web browsers
• Ladybird, and the WebRTC audio work in PR #11209
• WebKit, Introducing the Safari MCP server
• WebMCP draft
• 9to5Mac on the end of ChatGPT Atlas
• Engadget on the end of Arc
• Benzinga on Musk’s “no apps in five years” and on his “True” about browsers
• Ladybird adopts Rust and Changing how we develop Ladybird
• Mozilla’s firefox-devtools-mcp
• WebMCP positions: WebKit and Mozilla
• Chrome’s Manifest V2 deprecation timeline