Electron makes your app live inside its runtime. Its windows, its Node, its packaging. I wanted the opposite: Chromium as a library, the way you'd add SQLite.

zebkit is Blink, V8, PDFium and FFmpeg in one library you link into your own program, in C, Rust, Python or JavaScript. Your app keeps its own event loop, windows and toolkit. Where it needs the web it adds a view. It can be a window, a child of your own window (X11, NSView, HWND), or off-screen with the frames handed to you.

Against the latest Electron (45.2.1), on Linux: - 34% smaller (62 MB compressed) - cold start in 2.3 s instead of 6.6 - pages in 29% less memory - same DOM, text-layout and JavaScript speed

No Node: your app is native code, or JavaScript run on the engine's own V8.

Everything the engine would show the user or ask of the system is your app's to decide: - permissions, popups, downloads and certificates - network requests, at every stage - the window frame, so the page can be your title bar - menus, dialogs, notifications and tray icons - USB, HID and serial device pickers - screen capture

Without your code, a page gets nothing a cautious browser wouldn't give it.

For automation and AI agents, it speaks CDP as Chromium's own DevTools server, so Puppeteer, Playwright and any CDP client connect unchanged. It also runs Playwright's API natively inside the engine, with no CDP, no Node and no JSON between processes. A click takes 2 ms instead of 33 ms with Playwright on Chrome over CDP, and a screenshot 12 ms instead of 34. Playwright's own clients can attach to that with chromium.connect(), and there's an MCP server.

It also exports Chromium's own C libraries for your app (SQLite, BoringSSL, ICU, HarfBuzz, zstd and others), plus a full PDF API.

Chromium 157. Linux, macOS (Apple silicon) and Windows. cargo add zebkit, or pip install zebkit.

https://github.com/ikey4u/zebkit

I'd love feedback, especially from people who've hit Electron's or CEF's limits.

This got auto-flagged for being AI-generated. It would be much better if you wrote this kind of thing yourself. Your motivations and personal perspective on the project are much more interesting than an LLM’s summary of the readme (which is also a pretty tough read).

Does this library model lose chromium's process sandbox features? A quick search tells me "Electron applications heavily benefit from Chromium’s sandboxing features, and they have become a foundational pillar of modern Electron security." It doesn't immediately sound like your approach maintains that security.

Hi Riiiiichard!

>Electron makes your app live inside its runtime. Its windows, its Node, its packaging. I wanted the opposite: Chromium as a library, the way you'd add SQLite.

First of all, thank you for doing this! This is a great idea! Since I see that your account is relatively new here on HN, one of the first thing that you should understand about the HN message forums is that at this point in time, it is probably about 50% bot comments, and there seem to always be the (agenda-driven!) comments that a given source code repository was "AI generated", or allude to / imply that idea...

Yes, there are some AI generated github repositories out there, but whether a given repo is AI generated or not, in whole or in part, is not necessarily a measure of the underlying utility of the software!

(In other words, watch out for those comments! Some may be true -- but they are usually agenda-driven and biased as hell -- always do your own research!)

OK, getting back to Zebkit -- I think it's a brilliant idea!

Chromium as a library like SQLite -- brilliant!

>zebkit is Blink, V8, PDFium and FFmpeg in one library you link into your own program, in C, Rust, Python or JavaScript. Your app keeps its own event loop, windows and toolkit. Where it needs the web it adds a view. It can be a window, a child of your own window (X11, NSView, HWND), or off-screen with the frames handed to you.

Really nice! And no Electron, even better!

>Against the latest Electron (45.2.1), on Linux: - 34% smaller (62 MB compressed) - cold start in 2.3 s instead of 6.6 - pages in 29% less memory - same DOM, text-layout and JavaScript speed

Again, terrific!

>No Node: your app is native code, or JavaScript run on the engine's own V8.

Excellent! (Node is bloated as hell and many libraries import every unnecessary dependency under the sun... I don't mean to trash it, Node is tremendously useful for a variety of tasks, but it is in need of better dependency management...)

>Everything the engine would show the user or ask of the system is your app's to decide: - permissions, popups, downloads and certificates - network requests, at every stage - the window frame, so the page can be your title bar - menus, dialogs, notifications and tray icons - USB, HID and serial device pickers - screen capture. Without your code, a page gets nothing a cautious browser wouldn't give it.

That's the way to do it!

>It also exports Chromium's own C libraries for your app (SQLite, BoringSSL, ICU, HarfBuzz, zstd and others), plus a full PDF API.

Nice!

>I'd love feedback, especially from people who've hit Electron's or CEF's limits.

From a Software Engineer with 20+ years experience (me!) -- It's f'ing brilliant!

I'm sure we'll see a lot of great future software written around Zebkit (Fast, responsive non-Electron-based editors are the most immediate ones I can think of , but I'm sure we'll see a whole lot more!)

One request if I might -- In the future, you might want to support other JavaScript engines... if so, then the interfaces between Zebkit (JavaScript interface) and V8 (JavaScript implementation) should be as decoupled as possible. That might be a problem because V8 might already be tightly integrated with the rest of the source code. But if Google coded the Chrome/Chromium source code correctly, (I don't know, haven't looked at that code recently), then the Chrome/Chromium JavaScript interface with V8 would be coded in such a way to allow easy replacement of V8 with a different JavaScript engine.

In other words, the choice of the JavaScript engine would ideally be modular and at the person compiling the code's discretion!

Anyway, your work is absolutely brilliant!

(BTW, shoot me an email if you'd like to have a longer discussion -- peter.d.sherman@gmail.com)

I take it this means you lose the sandboxing from normal chromium/electron since it's a library being loaded inside the app process? Or does it still spin up i.e. a GPU sandbox process, an I/O sandbox process, etc?