Why Lightpanda Was Built in Zig: A Deep Dive into Performance and Simplicity

Lightpanda's development began with a critical choice of programming language. The decision to use Zig stemmed from a preference for simplicity and an acknowledgement that managing complex abstractions at scale in languages like C++ or Rust can be challenging. While Go was previously used for other projects, building a high-performance web browser from scratch necessitated a low-level systems programming language. Traditional C offered the required control but lacked modern tooling and safety features. This led to Zig, which struck an optimal balance.

Why We Built Lightpanda in Zig

Our core requirements for the Lightpanda browser were exceptional performance, straightforward simplicity, and robust modern tooling. Zig emerged as the ideal candidate, offering a simpler alternative to C++ and Rust, while providing superior tooling and safety compared to C, all without compromising on top-tier performance.

As we progressed with the browser's initial iterations and delved deeper into the language, we increasingly valued Zig's standout features: comptime metaprogramming, explicit memory allocators, and best-in-class C interoperability. Furthermore, the ongoing advancements in compilation times are a significant benefit.

Naturally, choosing a relatively new language like Zig, which is pre-1.0 and has a smaller ecosystem with occasional breaking changes, is a substantial commitment. However, our optimism for its future is shared by other notable projects, including Ghostty, Bun, TigerBeetle, and ZML, all actively building with Zig. The recent acquisition of Bun by Anthropic further signals growing interest from major tech companies.

Here's what our experience has revealed.

What Lightpanda Needs from a Language

Before delving into specifics, it's essential to understand the unique demands of building a browser for web automation.

Firstly, a powerful JavaScript engine was indispensable. Without one, a browser would be limited to static HTML, incapable of client-side rendering or dynamic content. We selected V8, Chrome's JavaScript engine, due to its state-of-the-art capabilities, widespread adoption (e.g., Node.js and Deno), and relative ease of embedding.

V8 is written in C++ and lacks a direct C API, meaning any language integrating with it must navigate C++ boundaries. While Zig doesn't directly interoperate with C++, it provides first-class C interoperability, and C remains the universal standard for systems programming. To bridge V8's C++ API with our Zig codebase, we leverage C headers primarily generated from rusty_v8, a component of the Deno project.

Beyond integration, performance and precise memory control were paramount. When processing thousands of pages or executing automation at scale, every millisecond is critical. We also required fine-grained control over short-lived allocations such as DOM trees, JavaScript objects, and parsing buffers. Zig's explicit allocator model perfectly addresses these requirements.

Why Not C++?

C++ was an obvious consideration, powering virtually every major browser engine. However, several factors gave us pause:

• Four Decades of Features: C++ has accumulated immense complexity over its history. It offers multiple ways to achieve almost anything—from template metaprogramming and various inheritance patterns to diverse initialization syntaxes. We sought a language that promoted a single, clear approach.
• Memory Management: Achieving fine-grained control in C++ demands constant vigilance against use-after-free bugs, memory leaks, and dangling pointers. While smart pointers offer some assistance, they introduce additional complexity and runtime overhead. Zig's explicit allocator model, where allocators are passed explicitly, clarifies memory management and naturally facilitates patterns like arena allocation.
• Build Systems: The frustrations of grappling with CMake or managing complex header file dependencies are well-known. For a small team aiming for rapid development, we wanted to avoid debugging build configuration issues.

This is not to diminish C++; it underpins incredible software. However, for a small team starting a project from scratch, simplicity was a key priority.

Why Not Rust?

Many frequently ask why Rust wasn't chosen, a valid challenge given its maturity, memory safety guarantees, excellent tooling, and thriving ecosystem.

Rust would have been a viable option. However, for Lightpanda's specific requirements, and frankly, for our team's experience level, it introduced friction we aimed to avoid.

The Unsafe Rust Problem

When tasks necessitate operations that conflict with Rust's borrow checker, developers often resort to unsafe Rust, which can be surprisingly difficult to manage effectively. Zack from Bun explores this topic extensively in his article, "When Zig is safer and faster than Rust".

Browser engines and garbage-collected runtimes are classic examples of codebases that frequently challenge the borrow checker. Developers constantly manage disparate memory regions—per-page arenas, shared caches, temporary buffers, and objects with intricate interdependencies. These patterns do not align cleanly with Rust's ownership model, leading to potential performance costs (e.g., using indices instead of pointers, unnecessary clones) or a reliance on unsafe code where raw pointer ergonomics are poor, making tools like Miri essential.

Zig adopts a different philosophy. Instead of enforcing safety primarily through the type system and then offering an escape hatch, Zig is explicitly designed for scenarios involving memory-unsafe operations. It provides robust tools to improve this experience, including non-null pointers by default, a GeneralPurposeAllocator that detects use-after-free bugs in debug mode, and pointer types with excellent ergonomics.

Why Zig Works for Lightpanda

Zig occupies a unique position. It's a simple, easy-to-learn language where explicitness is paramount: there's no hidden control flow or concealed allocations.

Explicit Memory Management with Allocators

Zig mandates explicit memory management through allocators. Every memory allocation requires you to specify which allocator to use. While this might initially seem tedious, it provides unparalleled control.

Here’s a practical illustration using an arena allocator:

const std = @import("std");

pub fn loadPage(_allocator: std.mem.Allocator, url: []const u8) !void {
    // Create an arena allocator for this page load
    var arena = std.heap.ArenaAllocator.init(_allocator);
    defer arena.deinit();

    // Everything gets freed here
    const allocator = arena.allocator();

    // All these allocations use the arena
    const dom_tree = try parseDom(allocator, url);
    const css_rules = try parseStyles(allocator, dom_tree);
    const js_context = try createJsContext(allocator);

    // Execute page, render, extract data...
    try executePage(js_context, dom_tree, css_rules);

    // Arena.deinit() frees everything at once, no leaks possible
}

This pattern is perfectly suited for browser workloads. Each page load receives its own arena. Once the page is processed, the entire memory chunk is deallocated instantly, eliminating the need to track individual allocations, manage reference counting overhead, or endure garbage collection pauses. (It's worth noting that individual pages can consume significant memory, leading us to explore mid-lifecycle cleanup strategies.) Furthermore, arenas can be chained to manage short-lived objects within a page's lifecycle.

Compile-Time Metaprogramming

Zig’s comptime feature enables code execution during the compilation phase. We leverage this extensively to minimize boilerplate when establishing bridges between Zig and JavaScript.

Integrating with V8 necessitates exposing native types to JavaScript. In most languages, this involves writing specific glue code for each type, often generated via macros (in Rust, C, C++). Macros, however, constitute a separate language with distinct drawbacks. Zig’s comptime allows us to automate this process seamlessly:

const Point = struct {
    x: i32,
    y: i32,

    pub fn moveUp(self: *Point) void {
        self.y += 1;
    }

    pub fn moveDown(self: *Point) void {
        self.y -= 1;
    }
};

// Our runtime can introspect this at compile time and generate bindings
runtime.registerType(Point, "Point");

The registerType function utilizes comptime reflection to:

• Identify all public methods declared on Point.
• Generate corresponding JavaScript wrapper functions.
• Create property getters and setters for x and y.
• Handle type conversions automatically.

This approach eradicates manual binding code and simplifies the addition of new types by using a unified language for both compile-time and runtime operations.

C Interop That Just Works

Zig’s C interoperability is a first-class feature, allowing direct import of C header files and invocation of C functions without the need for wrapper libraries.

For instance, we utilize cURL as our HTTP library. We can directly import libcurl C headers into Zig and use its C functions:

pub const c = @cImport({
    @cInclude("curl/curl.h");
});

pub fn init() !Http {
    try errorCheck(c.curl_global_init(c.CURL_GLOBAL_SSL));
    errdefer c.curl_global_cleanup();
    // business logic ...
}

This experience is as straightforward as programming in C, but with the advantages of Zig.

Furthermore, integrating C sources into the build system is exceptionally simple, allowing your Zig code and C libraries to be compiled together seamlessly:

fn buildCurl(b: *Build, m: *Build.Module) !void {
    const curl = b.addLibrary(.{
        .name = "curl",
        .root_module = m,
    });
    const root = "vendor/curl/";
    curl.addIncludePath(b.path(root ++ "lib"));
    curl.addIncludePath(b.path(root ++ "include"));
    curl.addCSourceFiles(.{
        .flags = &.{ 
            // list of compilation flags (optional)
        },
        .files = &.{ 
            // list of C source files
        }
    });
}

This ease of C integration effectively mitigates Zig's currently small ecosystem, as it enables the utilization of a vast array of existing C libraries.

The Build System Advantage

Zig incorporates its own build system, written entirely in Zig. While this might seem unremarkable, its simplicity is a refreshing contrast to tools like CMake. Adding dependencies, configuring compilation flags, and managing cross-compilation are all handled in a single, coherent framework with clear semantics. The consistency of using Zig for runtime, comptime, and the build system streamlines the entire development process.

Cross-compilation, typically a challenging aspect of development, becomes remarkably simple with Zig. Some prominent projects, such as Uber, primarily use Zig for its build system and toolchain capabilities.

Compile Times Matter

Zig boasts impressively fast compilation speeds. A full rebuild of our project completes in under a minute. While not as instantaneous as Go or interpreted languages, this speed ensures a responsive feedback loop during development, significantly outperforming Rust or C++ in this regard.

Fast compilation is a central focus for the Zig team. As a small team with a self-hosted language (Zig is written in Zig), rapid compilation is crucial for their own development velocity. To this end, they are developing native compiler backends (bypassing LLVM), an ambitious yet successful endeavor. This custom backend is already the default for x86 in debug mode, yielding substantial improvements in build times (e.g., 3.5x faster for the Zig project itself). Incremental compilation is also actively under development.

What We’ve Learned

After months of developing Lightpanda with Zig, several key insights have emerged:

• Manageable Learning Curve: Zig's inherent simplicity allows developers to grasp the entire language within a few weeks, a significant advantage compared to Rust or C++.
• Allocator Model Efficiency: The ability to instantiate arena allocators per page load, per request, or per task provides granular memory control without the overhead of tracking individual allocations.
• Supportive Community: While still growing, the Zig community is small but highly helpful. Active discussions on Discord and ziggit.dev offer valuable support, and the language's straightforward design often allows developers to find answers by examining the standard library source code.

Conclusion

Lightpanda's realization owes much to the dedication of the Zig Foundation and its vibrant community. Zig has empowered a small team to construct a complex application like a web browser with a clear mental model and without sacrificing performance.

For those interested in Zig’s design philosophy or eager to understand its compiler and allocator model, the official documentation is the definitive starting point.

You can also explore the Lightpanda source code and follow the project on GitHub.

Consider signing up to test the cloud version of Lightpanda.

FAQ

Is Zig stable enough for production use? Zig remains pre-1.0, meaning breaking changes can occur between versions. However, we've found it sufficiently stable for our production environment, particularly as the ecosystem has largely standardized on tracking the latest tagged releases rather than main. The language design is robust, and most inter-version changes are improvements worth adapting to. Developers should be prepared to update code when upgrading Zig versions.

What’s the hardest part about learning Zig? The allocator model requires an adjustment for those accustomed to garbage-collected languages, as it necessitates conscious thought about memory allocation and deallocation. Yet, compared to Rust’s borrow checker or C++’s manual memory management, it proves relatively straightforward once the patterns are understood.

Can Zig really replace C++ for browser development? For building specialized browsers like Lightpanda, yes, it's entirely viable. However, fully replacing behemoths like Chromium or Firefox is improbable, given their millions of lines of C++ code and decades of optimization. In such projects, Rust is more likely to complement C++ over time (e.g., Firefox's use of Servo). For new projects where you control the codebase, Zig is absolutely a strong contender.

Where can I learn more about Zig? Begin with the official Zig documentation. The Zig Learn site offers practical tutorials. Engage with the active community on Discord or ziggit.dev, where developers actively assist newcomers. Due to the language's simplicity, reading standard library source code is also an effective learning method.