Ladybird browser spreads its wings

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.