← Back to archive

Repo of the Day

LadybirdBrowser/ladybird

Published: Jul 3, 2024

Open repository ↗

Truly independent web browser

Summary

Ladybird is a standalone, independent web browser written in C++ that uses a custom rendering engine built on web standards rather than depending on existing engines like Chromium or Gecko. The project is in a pre-alpha state, and the README explicitly states it is "only suitable for use by developers," not end users. It is distributed under the 2-clause BSD license.

What it is useful for

Ladybird is most useful for engineers who want to study or contribute to a from-scratch browser engine. The README describes a multi-process architecture: a main UI process, separate WebContent renderer processes per tab, an ImageDecoder process, and a RequestServer process. Image decoding and network requests are intentionally moved out of the renderer for robustness against malicious content, and each tab runs in its own sandboxed renderer.

The codebase includes a stack of libraries that originated with SerenityOS and now support the browser:

  • LibWeb (rendering), LibJS (JavaScript), LibWasm (WebAssembly)
  • LibCrypto and LibTLS (cryptography and TLS), LibHTTP (HTTP/1.1 client)
  • LibGfx (2D graphics and image decoding), LibUnicode, LibMedia, LibCore, LibIPC

For C++ developers, this is a single place to read implementations of layout, parsing, a JS runtime, TLS handling, and IPC plumbing without the legacy baggage of older engines.

How engineers can use it

The README points to a dedicated Documentation/BuildInstructionsLadybird.md file and notes that Ladybird builds on Linux, macOS, Windows (via WSL2), and other Unix-like systems. The exact commands and toolchain prerequisites live in that file rather than the top-level README, so engineers should consult it directly for setup steps. Code-level documentation is collected in the Documentation/ folder, and contribution entry points are described in Documentation/GettingStartedContributing.md.

Beyond building and running it locally, realistic ways to engage include reading the library source to learn how individual browser subsystems are implemented, opening issues using the policy in CONTRIBUTING.md and ISSUES.md, and joining the project's Discord for development discussion.

Because the project is pre-alpha, do not expect production stability, broad web compatibility, or strong security guarantees. Treat it as an engineering reference and an active work in progress rather than a daily-driver browser.