Making A Browser Is Harder Than You Think (Ft Andreas Kling)

Ladybird’s lead developer, Andreas Kling, frames browser-building as a long, grinding engineering problem—one that starts with “from-scratch” web standards work but quickly becomes dominated by compatibility, spec churn, and maintenance. The browser began as a small project inside Serenity OS—initially aimed at rendering rich text via HTML and CSS—then grew into a standalone effort when the combined operating system + browser codebase became too socially and technically mismatched for contributors, testing, and CI.

Kling traces Ladybird’s evolution from a hobby to a community-backed project with over a thousand contributors to Serenity OS, and a separate browser effort focused on shipping a real engine. Ladybird is built to implement core web specifications—HTML, CSS, JavaScript, and supporting standards like URL encoding—while selectively using third-party libraries for areas outside the team’s core expertise. For graphics, the project moved from its own stack to Skia; for networking it uses curl; and for GPU/GL context handling it relies on an angle library approach to avoid writing low-level platform glue for every target.

A major emphasis is JavaScript compliance. Kling says Ladybird’s JavaScript engine (LiJS) is highly compliant with the TC39 test suite Test262, citing a recent top score around 97% and noting that Firefox briefly pulled ahead after a code dump for the Temporal proposal. He also stresses that “spec compliance” doesn’t automatically translate to perfect real-world compatibility, because the web’s behavior is shaped by countless interactions among features.

CSS is presented as the most chaotic part of the platform. Kling describes the mental-model traps that arise from layout rules—especially when widths, heights, and percentages depend on each other—and the way CSS specs keep evolving. He estimates major “earth-shaking” spec rewrites happen only once or twice per year, but the day-to-day changes still force constant revalidation. Ladybird’s approach is to keep scope manageable, accept that many fixes can break other combinations, and prioritize what breaks in practice.

On usability, Kling is blunt: Ladybird is pre-alpha and not suitable for average daily browsing. He personally tests it by opening random links and tracking what fails, with GitHub workflows working better than most public sites. He highlights user-agent string decisions as a practical pain point—Ladybird avoids lying by default, but that can break sites that gate behavior on browser identity.

The conversation also widens into antitrust and funding realities. Kling argues that if Google’s Chromium dominance is disrupted, standards work and browser development capacity could stall because much of the ecosystem’s engineering and money is concentrated around Chromium. He hopes new engines will emerge to restore choice, and he cites Servo as another engine effort that has faced instability but is restarting after Linux Foundation support.

Finally, Kling explains why Ladybird is funded as a nonprofit with constrained sponsorship: logos and public credit, not influence. He says the team stays small to avoid becoming dependent on any single donor, and he positions the next major hurdle as maintenance—an “infinitely long tail” of keeping pace with a living web platform. Ladybird’s roadmap includes an alpha release target in 2026, with the expectation that feedback will become more meaningful once the browser is closer to real-world use.