The Ladybird browser project

An experimental C++ web browser engine called Ladybird, spun out of the SerenityOS project, is drawing attention for how quickly a small team has made it render major sites and implement modern web standards from scratch. Commenters see it as a rare new contender to the Blink/WebKit/Gecko triopoly and a hedge against Google’s growing influence over de facto web standards, but question its long‑term security, funding stability, permissive licensing, and reliance on Discord for coordination. Many note that today’s richer specifications and shared test suites make such a project more feasible than in the past, while warning that matching the security hardening and feature surface of mainstream browsers remains a huge undertaking.

Project scope and progress

  • Many commenters are impressed that a small team built a new engine that already renders complex sites (e.g. GitHub, Google Docs) reasonably well.
  • Prior browser/engine experience and a custom C++ standard library are seen as key enablers of the project’s pace.
  • The “from scratch” mono-repo approach (own string class, own image decoders, SVG, JS engine, JIT, even a new language) is praised for speed of iteration and coherence, but some see it as overkill.

Funding, sponsors, and motivation

  • Sponsorships from Shopify and a real-estate site (which paid to make their site render correctly) are highlighted as notable corporate support.
  • Some worry that no new sponsors since mid‑2023 may signal funding challenges.
  • There’s debate over whether this is “just for fun” vs. a serious long‑term browser; several argue that many major projects started as hobbies, but that expectations around security should be tempered for now.

Compatibility, standards, and browser monoculture

  • Many commenters report Firefox works for nearly all sites; a minority cite specific sites that only work in Chrome/Blink.
  • There’s sustained criticism of Chrome/Blink dominance and developers targeting only that engine; some blame browser vendors, others front‑end teams and management.
  • Standards and large shared test suites (Web Platform Tests, JS test262, Interop initiatives) are credited with making new engines more feasible today.
  • Ladybird’s pragmatic strategy of implementing what’s needed for popular sites is contrasted with other alternative engines (e.g. Servo, NetSurf), which tend to render modern pages poorly.

Security and implementation choices

  • Using custom media decoders and C++ draws concern; skeptics argue even large vendors struggle to secure such code.
  • Supporters reply that smaller, cleaner code, strict sandboxing, fuzzing, and sanitizers can make a new stack competitive on security, though no one claims it’s bulletproof.
  • Some want eventual rewrites in the project’s memory‑safer language; others note work on that language has slowed.

Community, licensing, and accessibility

  • Use of Discord for coordination and a permissive (“pushover”) license are criticized by some who prefer copyleft and fully free infrastructure.
  • The lack of official binaries/ISOs and a “technical users only” stance are seen by some as abrasive gatekeeping, by others as a deliberate way to limit nontechnical support burden while the project is young.