Zebkit enables developers to integrate the Blink, V8, PDFium, and FFmpeg components of Chromium as a shared library rather than a full runtime environment. This approach allows a host application to maintain its own native event loop, windows, and toolkit while adding web views as children of its own UI or as off-screen frames.
The Zebkit Architecture
The project creator, Riiiiichard, describes Zebkit as a way to add web capabilities to a program in the same way one would add a library like SQLite. It provides the core engine components—Blink for rendering, V8 for JavaScript, PDFium for PDF handling, and FFmpeg for media—as a single library that links into native code.
Unlike Electron, which bundles the application inside its own runtime and packaging, Zebkit allows the host application to keep its own event loop and windows. The engine can be integrated as a window, a child of an existing window (such as X11, NSView, or HWND), or as an off-screen component where the library hands frames back to the application to draw.
Performance and Size Comparisons
Riiiiichard reports that Zebkit offers significant efficiency gains over the latest Electron version on Linux. Specifically, it is 34% smaller (62 MB compressed), features a cold start time of 2.3 seconds compared to Electron's 6.6 seconds, and uses 29% less memory for pages while maintaining the same DOM and JavaScript speed.
The reduction in size is achieved through specific build options that turn off unnecessary features. However, the creator notes that certain components like WebRTC and video playback must remain because Blink depends on them and most applications require media support.
Community Discussion and Trade-offs
Commenters on Hacker News discussed how Zebkit differs from the Chromium Embedded Framework (CEF). One commenter, writing as torginus, noted that while CEF is widely used for game lobbies and overlays, it often keeps Chrome 'vanilla,' making it difficult to upstream new versions. In contrast, Zebkit's more granular approach may allow for more specific optimizations, though it remains to be seen how it handles the complexity of those changes.
Other participants raised concerns regarding security and process management. One commenter, joahnn_s, questioned the safety of loading Chromium as a shared library via CFFI, noting that a crash in the engine could crash the entire application process. Riiiiichard clarified that while the embedding interface is a C API, Zebkit still uses Chromium's internal sandboxed renderer processes and shared memory to maintain isolation.
Integration and Limitations
Zebkit exports several Chromium C libraries, such as BoringSSL, zstd, and FFmpeg, so that host applications do not need to compile or ship them twice. This helps manage the dependencies of the underlying engine while keeping the host application's footprint manageable.
While the project provides bindings for Rust, Python, and JavaScript, some specific integrations remain in progress. For example, there is currently no native Go binding, though the C API is intended to be usable through cgo. The project's primary goal is to provide a 'slim' version of Chromium that gives the host application total control over permissions, downloads, and certificates.