Ladybird browser spreads its wings

Original Article ↗ Hacker News Discussion ↗

A new independent web browser engine called Ladybird is attracting both enthusiasm and skepticism as it aims to challenge today’s near‑monopoly of Chromium- and WebKit-based browsers. Commenters praise its rapid progress, educational value, and ambition to prove a modern engine can be built without Big Tech backing, but note it remains far from daily-driver ready, lacks full security hardening, and is written in C++ rather than a memory-safe language. The conversation broadens into concerns about Firefox’s dependence on Google, the difficulty of sustaining alternative engines, and whether the web’s growing complexity makes such efforts impractically hard or urgently necessary.

Project goals & value proposition

  • Seen as an “experimental engineering” effort to build a fully independent web stack and prove a modern browser engine can be created without big-tech resources.
  • Some frame it as “basic engineering” rather than a product with a business-style “value proposition”; the value is in the open, incremental development process.
  • Others see practical value mostly in offering another engine to counter browser monoculture, even if it never reaches mass market.

Maturity, capabilities & expectations

  • Consensus: the engine is very early and far from being a daily driver; major sites still break and performance/stability lag far behind Chrome/Safari/Firefox.
  • Many doubt it will ever reach “critical mass”; others counter that past engines (KHTML→WebKit→Blink) also started small.
  • Some users are simply “irrationally excited” that a fresh engine exists at all, despite low short‑term practicality.

Learning & contributing

  • Multiple commenters say it’s a good learning playground with broad scope and approachable tasks (e.g., simple features like find‑in‑page).
  • Others warn that browser development is inherently deep and that motivation lasts longest when you’re scratching your own itch, not just “learning on a big project.”

Browser ecosystem, monoculture & Firefox debate

  • Many want Ladybird as an additional independent engine beyond Blink and WebKit; some argue Firefox already breaks monoculture, others say its heavy funding from Google undermines independence.
  • Intense debate around Mozilla’s choices: telemetry, “studies,” ads, acquisitions, and cancelled efforts like Servo; some still consider Firefox solid and configurable, others have lost trust.
  • Several worry that standards effectively ratchet toward whatever Chromium implements, making life hard for new engines and subsets.

Implementation choices: C++, Rust & security

  • A major thread questions building a hostile‑content processor in C++ in 2024, citing memory‑safety concerns and studies linking many exploits to unsafe memory.
  • Defenses of C++ include:
    • Author proficiency and project origins as a personal/hobby effort.
    • Lack of proven, large‑scale Rust/browser examples; suspicion of “rewrite it in Rust” as cargo‑cult.
    • Argument that many modern JS‑engine bugs are subtle logic/JIT issues where language choice helps less.
  • Others point to alternative approaches (Ada, ATS, formal methods, sandboxing) but acknowledge practicality and ecosystem issues.
  • Discussion notes that current sandboxing on non‑SerenityOS appears minimal; plans exist but are “nowhere near” the aggressiveness of Chrome‑style sandboxes.

Architecture, platforms & dependencies

  • Ladybird now targets Linux and macOS and has dropped SerenityOS as a primary target, partly because using third‑party libraries conflicts with SerenityOS’s “no third‑party code” philosophy.
  • Uses Qt for browser chrome and platform integration; some worry this makes the project “pointless” compared to Qt WebView (Chromium), but others stress Ladybird’s engine is independent of Qt.
  • There is per‑tab/process isolation and architectural docs; deeper hardening is planned but incomplete.

Alternative web visions & subsets

  • Some wish for a browser that implements only a strict subset of HTML/CSS/JS/APIs for simplicity, speed, and security, perhaps with fallbacks to a “big” browser for complex sites.
  • Others argue subset browsers fail in practice: once mainstream engines support a feature, sites rely on it and any browser lacking it is seen as broken.
  • Proposals include:
    • A “new web” or separate protocol (compared to Gemini) that deliberately avoids complexity.
    • Browsers that delegate PDFs, video, and JS‑heavy pages to external tools.
    • Acknowledgment that many text‑centric sites still work with little or no JS, but modern webapps do not.

Adoption, funding & future prospects

  • Skeptics think the project may eventually pivot to Chromium or stall once the full scale of the work hits; others strongly doubt this, noting years of steady progress and that using Chromium would erase the project’s raison d’être.
  • Some hope for legal or policy interventions (e.g., browser‑choice ballots, constraints on major platforms) to prevent further consolidation and give alternative engines room to matter.
  • Overall sentiment: strong admiration for the ambition and execution so far, tempered by realism about how hard it is to catch up to mature engines and the ever‑growing web platform.