Ladybird: a truly independent browser with its own engine

The Ladybird project has set itself a challenge that few dare to tackle today: to build a browser with a own engine from scratch, without reusing the core of other browsers. This means that it doesn't rely on Blink, WebKit, or Gecko, but rather pursues an independent implementation that respects modern web standards and that, with There, be fully usable for browsing without missing anything.

This approach entails very specific architectural and development decisions. On the one hand, a multi-process structure that isolates critical tasks such as rendering, image decoding, and network connections has been prioritized, and on the other, a sensible combination of legacy proprietary libraries and third-party components for common functionality has been chosen. Overall, the goal is build a “real” and completely independent browser, not a wrapper over the work of other engines.

What is Ladybird and why is it different?

Ladybird is not intended to be a pretty facade over other technologies: it is a browser with a innovative web engine It's implemented following standards, aiming for compatibility and robustness. The decision not to borrow code from popular engines sets a demanding standard, but also offers complete control over every layer of the system, from HTML and CSS parsing to JavaScript execution and DOM management.

In addition to the commitment to its own engine, the project emphasizes that it will not adopt any other engine in the future. This is not just a declaration of intent; in practice, it means that Ladybird's evolution will depend on its ability to implement and optimize each web specification and an architecture that facilitates security and performance. It's not the easy path, but it is the one that guarantees true independence.

The team aims for the browser to go beyond a tech demo. Their goal is to deliver a complete, everyday application with a fluid interface, tab isolation, and a solid foundation for playing media, running scripts, and rendering complex pages. reliability. With that goal, the constant review of standards and real-world testing is a central part of the work, as well as user functions such as browser bookmark synchronization that facilitate daily use.

Relationship with SerenityOS and evolution of the project

Historically, Ladybird has shared DNA with SerenityOS, a system that focuses on developing almost everything from scratch. Because of this heritage, the browser today uses several libraries from that ecosystem, which has allowed rapid progress in aspects such as web rendering, JavaScript execution, and interprocess communication. With the separation underway (a fork), Ladybird is no longer tied to the “everything from scratch” philosophy and has been opened to third-party libraries for common tasks that are not its differential value.

This pragmatic shift doesn't contradict its independence as an engine: it simply recognizes that, for image, audio or video formats, cryptography or graphics, there are mature components worth integrating. In fact, the project already uses some of the same external libraries that other established browsers use, reserving home-made construction for the core of the web engine.

Among the components of SerenityOS that today form part of the Ladybird base are the following, each covering a key piece of the puzzle:

• LibWeb: web rendering engine.
• LibJS: JavaScript engine.
• LibWasm: WebAssembly implementation.
• LibCrypto/LibTLS: Cryptographic primitives and transport security (TLS).
• LibHTTP: HTTP/1.1 client.
• LibGfx: 2D graphics library, image decoding and rendering.
• LibUnicode: Unicode and locale support.
• LibMedia: audio and video playback.
• LibCore: Event loop and operating system abstraction layer.
• LibIPC: Interprocess communication.

The transition to a more independent project doesn't erase these foundations, but it does allow for a case-by-case evaluation of where third-party libraries might be appropriate to integrate. Thus, for media formats, encryption, or graphics, the compatibility and security provided by proven solutions are prioritized, while the team focuses its efforts on the heart of the engine and compliance with standards.

Multi-process architecture and security

Ladybird adopts a multi-process architecture from the start. There is a main interface (UI) process that orchestrates the user experience and coordinates with multiple WebContent rendering processes. Each tab runs in its own renderer process, which improves isolation, stability, and reliability. to maximise security and your enjoyment.. Thanks to this design, a failure on one page should not drag down the others, and the browser can apply sandboxing per tab.

In addition to the rendering processes, there are specialized processes for sensitive tasks. One handles image decoding (ImageDecoder) and another handles network traffic (RequestServer). By running these functions outside the main process, Ladybird reduces the attack surface and improves robustness against attacks. malicious contentThe idea is that a vulnerability in the decoding of an image or in the handling of an HTTP response does not compromise the rest of the system or the entire browser.

This approach to separate responsibilities also improves performance. Processes can be scheduled independently by the operating system, isolating heavy loads and avoiding blocking from the main thread. In practice, this results in a more responsive interface and greater resilience when a specific tab or site misbehaves. Thus, multiprocess architecture becomes a pillar of reliability and sustained performance.

Supported platforms and user experience

In terms of supported systems, Ladybird works on Linux, macOS and Windows using WSL2, as well as on other operating systems. UnixThis platform variety is important because it removes the barrier to entry for developers and users who want to test the project in their usual environment. Whether you work on desktop Linux, use macOS on your laptop, or develop on Windows with the Linux subsystem, you'll be able to run and evaluate Ladybird without excessive complications.

The user experience is based on the separation between the interface and the content processes. This allows the main window to remain fluid even when a complex site demands a lot of CPU or memory. At the same time, the project aims to achieve a "usable" state for the modern web, a goal that requires polishing the engine, expanding standards support, and perfecting media playback, font handling, layout, and execution. Intensive JavaScriptPart of that experience includes managing annoying elements like pop-up ads that affect navigation.

Construction and compilation of the project

If you want to build Ladybird yourself, the team refers to the project's build instructions. There you'll find the steps and dependencies needed to prepare the environment, compile the various components, and run the browserSince this is a proprietary engine with several orchestrated pieces (UI, renderers, image decoder, request server), it's crucial to follow those guidelines to ensure everything fits together as it should.

In parallel, the use of third-party libraries for common functionalities (image, audio, and video formats; encryption; graphics, etc.) simplifies support for common use cases and avoids reinventing the wheel. This balance is key: engine independence is preserved, but support for auxiliary technologies that make navigation viable from the start is accelerated. The expected result is a reasonable installation curve and a more solid technical base.

Code documentation and resources

Code-related documentation is centralized in the repository's documentation folder. It describes components, internal flows, conventions, and other details necessary to understand the project structure and contribute changes. If you're new to the project, it's a good idea to review this material to get a mental map of the browser layers and their interaction.

Community communication revolves around a Discord server, where technical decisions are discussed, questions are answered, and efforts are coordinated. Participating there will allow you to learn firsthand about development priorities, seek guidance, and propose improvements. It's a useful meeting point for both those coding the core engine and those testing the browser, reporting bugs, or making suggestions. new features.

How to start contributing and rules for issues

If this is your first contribution, it's a good idea to read the Getting Started Contributing guide. This document explains how to prepare the environment, what code style to follow, how to organize patches, and what expectations there are for the quality of contributions. Getting started through this door will save you time and help your changes be reviewed and accepted more quickly, as they follow the criteria established by the team. applies in everyday life.

Before opening an issue, the project asks you to review its issue policy and detailed bug reporting guidelines. This ensures that reports contain sufficient information (reproduction steps, environment, relevant logs) and that existing requests are not duplicated. Adhering to these standards reduces noise and optimizes the team's response, allowing them to focus on real bugs and other issues. most urgent priorities.

For more extensive changes, the full contribution guidelines are documented in the file. CONTRIBUTING.md. They specify the review processes, how to structure commits, what criteria are applied in integration, and how to coordinate efforts to avoid branch clashes or duplicate work. Following these guidelines is the most effective way to accelerate your contribution and maintain the repository quality.

Using third-party libraries: pragmatism with a sense of purpose

After separating from SerenityOS as an independent project, Ladybird has taken the liberty of incorporating third-party libraries where they add the most value. In areas such as image format decoding (PNG, JPEG, etc.), audio and video containers, modern encryption, and graphics APIs, the open source community offers well-proven components. Integrating them doesn't compromise the goal of building a proprietary engine; on the contrary, it allows us to dedicate the majority of the effort to properly implementing it. HTML, CSS, JavaScript and WebAssembly.

The team also acknowledges that it already uses some of the same libraries used by other browsers. This is positive: they share battles in areas where the standard is clear and where it makes sense to add a mature foundation. The promise that remains unchanged is that Ladybird will not replace its engine with another; core independence is the project's hallmark, and the use of third-party resources is limited to what complements that mission without diluting it. It's a balance that combines technical ambition and pragmatism.

Goal: A complete browser for the modern web

The horizon is not modest: building a complete and usable browser. That means demanding performance on sites with heavy scripts, support for complex fonts and typography, a layout with modern specifications, reliable audio and video playback, and stable behavior under load. To get there, Ladybird relies on its multi-process architecture and a constant focus on compliance with web standards.

In parallel, the testing process, community feedback, and structured issue reporting serve to detect bottlenecks, compatibility gaps, or regressions. With its own engine, each advancement consolidates a differentiating asset: the internal knowledge of how and why each piece is implemented. Ultimately, this translates into a platform capable of innovating without depending on the pace and decisions of other engines, maintaining a autonomous roadmap.

License and project philosophy

Ladybird is released under a 2-clause BSD license. This choice facilitates adoption and allows the browser or parts of its stack to be integrated into projects with different licensing models. The combination of openness, engine independence, and an active community that discusses on Discord and documents in the repository creates an environment conducive to those who want to contribute without unnecessary friction. If you value a project that prioritizes core control, adherence to standards, and a clear stance on security, This license fits very well.

Ladybird's path isn't the shortest, but it offers the most freedom in the long run. An engine designed from the ground up, an architecture that separates critical processes, the intelligent use of external libraries for additional work, and clear contribution rules paint a project with a clear path. If you're interested in trying it out, check out the documentation, consult the compilation instructions, and visit the project's Discord: there you can answer questions, propose ideas, and see firsthand how this project is evolving. truly independent browser.