How does this differ from CEF(Chromium Embedded Framework)?
That's also a fairly pared down version of the Chrome engine, designed for embedding used by tons of projects, like games for their in game lobbies or OBS for their Web overlays.
Personally, my problem with CEF is that it keeps Chrome fairly vanilla - and there's a lot of things in there that you wouldn't want to include in your user app.
But there's a reason they did it like this - if they really took an axe to Chrome's codebase, they'd basically lose the ability to upstream new versions.
Zebkit on the other hand sounds like it's gonna be more granular - we'll if they cope with this better, but I think there's definitely a market for a much more lightweight browser engine that's broadly compatible - for example, just getting rid of sandboxes and process isolation would be a huge but incompatbile change.
So would be dropping large modules like WebRTC or video playback or webusb or whatever, that I'm sure 99% of apps don't end up using.
Also, very much with you in terms of exposing those libs ( like PDFium and FFmpeg ) to consumers, it lowers the shipping burden by quite a bit and just enables so much.
A note to anyone going down this road, just as an aside: actually shipping w/ Chromium ( and especially w/ FFmpeg ) can get complicated. If you're shipping on Mac OS, you'll want to worry about notarizing all your helpers along with your main process ( I'm assuming Zebkit still running w/ helper processes ). Similar w/ FFmpeg if you're linking to the FFmpeg libs. And, w/ FFmpeg, just validating that your license compliance is in fact what you want to be shipping w/ - FFmpeg has GPL and LGPL modes, so making sure you have selected the right one is important. If I recall Blink is LGPL as well, so making sure you meet what's required there has some distribution effects that are important.
joahnn_s
I don't understand. CEF exists; why load it as a shared lib/cffi? You just expose your app's process to all the issues that a browser can have, including security issues
In most languages, CFFI crashes the whole app process since it's the same process. Maybe for personal stuff, it can be suitable, but nothing serious
prologic
This is pretty interesting! I've created a web browser for GoNix (https://gonix.dev) using the CEF (Chromium Embedded Framework), which works quite well, but requires shared memory and a pipe, but embedding Chromium as a library sounds even more intriguing. I might give this a go! Thanks for sharing!
show comments
amelius
Will this work as a shared library? I.e., the hundreds of megabytes will be shared between different applications? If not, maybe running on a browser is still the better option?
show comments
weitzj
Now please somebody make a Browser in the Terminal. Using libghossty and Kitty graphics.
swiftcoder
I love that we're calling something that embeds pretty much the whole of Chromium "slim" and "light". Slightly smaller/faster than Electron is not the bar I would necessarily choose to measure software against.
rq1
That’s an interesting project name for whoever lives in the Middle East.
shinryuu
What kind of title is this?! Who ever lived in a runtime?
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.
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.
How does this differ from CEF(Chromium Embedded Framework)?
That's also a fairly pared down version of the Chrome engine, designed for embedding used by tons of projects, like games for their in game lobbies or OBS for their Web overlays.
Personally, my problem with CEF is that it keeps Chrome fairly vanilla - and there's a lot of things in there that you wouldn't want to include in your user app.
But there's a reason they did it like this - if they really took an axe to Chrome's codebase, they'd basically lose the ability to upstream new versions.
Zebkit on the other hand sounds like it's gonna be more granular - we'll if they cope with this better, but I think there's definitely a market for a much more lightweight browser engine that's broadly compatible - for example, just getting rid of sandboxes and process isolation would be a huge but incompatbile change.
So would be dropping large modules like WebRTC or video playback or webusb or whatever, that I'm sure 99% of apps don't end up using.
Nice. I'm a heavy CEF user on ZShot ( https://zshot-app.com , https://zshot-cli.com ), but strongly with you on this sort of thing should be easier to integrate.
Also, very much with you in terms of exposing those libs ( like PDFium and FFmpeg ) to consumers, it lowers the shipping burden by quite a bit and just enables so much.
A note to anyone going down this road, just as an aside: actually shipping w/ Chromium ( and especially w/ FFmpeg ) can get complicated. If you're shipping on Mac OS, you'll want to worry about notarizing all your helpers along with your main process ( I'm assuming Zebkit still running w/ helper processes ). Similar w/ FFmpeg if you're linking to the FFmpeg libs. And, w/ FFmpeg, just validating that your license compliance is in fact what you want to be shipping w/ - FFmpeg has GPL and LGPL modes, so making sure you have selected the right one is important. If I recall Blink is LGPL as well, so making sure you meet what's required there has some distribution effects that are important.
I don't understand. CEF exists; why load it as a shared lib/cffi? You just expose your app's process to all the issues that a browser can have, including security issues
In most languages, CFFI crashes the whole app process since it's the same process. Maybe for personal stuff, it can be suitable, but nothing serious
This is pretty interesting! I've created a web browser for GoNix (https://gonix.dev) using the CEF (Chromium Embedded Framework), which works quite well, but requires shared memory and a pipe, but embedding Chromium as a library sounds even more intriguing. I might give this a go! Thanks for sharing!
Will this work as a shared library? I.e., the hundreds of megabytes will be shared between different applications? If not, maybe running on a browser is still the better option?
Now please somebody make a Browser in the Terminal. Using libghossty and Kitty graphics.
I love that we're calling something that embeds pretty much the whole of Chromium "slim" and "light". Slightly smaller/faster than Electron is not the bar I would necessarily choose to measure software against.
That’s an interesting project name for whoever lives in the Middle East.
What kind of title is this?! Who ever lived in a runtime?
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.