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).
Agreed. I still write READMEs or anything human-consumable by hand.
The project is very interesting and opens up a lot of use cases - like a replacement for JSDOM in UI testing, a replacement for puppeteer/playwright in e2e testing, or even a base to build a single binary web browser MCP.
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?
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.
>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 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, choice of JavaScript engine should 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)
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!
Thanks! I'd be interested to hear how it works out for GoNix.
One clarification: Zebkit still uses Chromium's sandboxed renderer processes and shared memory internally. The embedding interface is a C API: your application links the library, keeps its own window and event loop, and can either embed a web view or receive off-screen frames to draw itself.
There's no Go binding yet, but the C API should be usable through cgo. If you give it a try, I'd love to hear where it fits your setup and where the integration gets awkward. Thanks for sharing your use case!
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?
Yes—it’s a shared library, so apps using the same installed copy can share disk space and read-only code pages. Separate bundled copies won’t automatically do that, and each app still has its own runtime memory.
A browser is a good choice if it fits your app! Zebkit is for embedding Chromium into a native app while keeping control of the host.
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.
Yes it would be interesting to know what the pros and cons of this are compared to CEF. CEF is a massive PITA so it would be great to have an alternative, honestly
Where zebkit easier thane CEF:
1. setup: cargo add zebkit for rust, pip install zebkit for python. Golang bindings is planned
2. your event loop
3. a plain C api with rust, python, and node-free js bindings on the top
4. offscreen rendering
6. batteries: PDFium API, 7000+ API from chroium's or its dependencies
7. automation: playwright api in native with no cdp and node required
8. size: well, smaller but not much (1/3 smaller than latest electron, measured on linux)
Where CEF is still ahead:
1. Maturity: it's a product over decade and a big community, zebkit is rather young, but I will keep maintain it
2. platform: zebkit ships linux x64, macos sillicon and windows x64, cef covers mac intels, arm linux and many others.
3. missing pieces: zebkit has no printing, web bluetooth, wideevine and so on
Zebkit is still a young project, and I’d love to hear your feedback to help it keep improving.
I agree with you on the core point: the same layer (zebkit embeds chromium using Content API), staying sync with upstream (it carries 60+ patches), the size reduce (using build options such as turning off features).
For the size, I have some more to address: the real weight comes from Blink, V8, skia, network stack and media. WebRTC cannot be dropped since Blink depends on it. Video playback is need by most apps so it stays. And the webusb is small, drop it has little benefit.
The main differences are mostly from shape, not the engine:
1. Exposed as a library with bindings (rust, python, JS without node) that can be run in your application's own event loop
2. Almost everything in the engine have a hook point such as permission, network, dialog, menus ..
3. Exported Chromium's C Library (such as boringssl, zstd, ffmpeg ..) for your app so you do not need compile it or ship it twice such as ELectron.
4. Exported feature rich PDF library (pdfium with improved)
5. Playwright inside, no cdp and no node are required
> designed for embedding used by tons of projects, like games for their in game lobbies or OBS for their Web overlays.
Probably the two biggest user's of CEF (in terms of user base exposed to it daily) would be Steam and Spotify. Both relatively fast and efficient, compared to their peers, albeit the UX is another question.
Also note Google actively detects Chromium embedders like CEF via hidden heuristics and doesn't allow users to use it to login to any Google account. You are expected to do oauth in your native app instead.
If this gets popular, expect Google to block it too.
> there's definitely a market for a much more lightweight browser engine
Yep.
My sciter[.com] dll is about 18mb on Windows which is 10 times less than zebkit (171.2 Mb). And sciter's cold start (window creation, document loading and painting) is around 60ms that is 38 times less than 2.3 seconds of zebkit.
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.
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
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 think energies should go towards something like sciterjs, or equivalent tech, with with a small footprint gives a great cross platform DX. I recall the sciterjs author a few years ago tried to put together some donations to open source, but it didn't go through.
Electrobun was an effort recently (but that too decompresses to ~70MB). There was antjs or something, which seems to have gone nowhere. Small size, scriptable, cross platform, huge library - whoever cracks this has the platform of the future. (No wonder TUIs are doing so well.)
why 'zeb' ? its a vulgar word for penis. could be better picked since it doesnt seem to relate to anything else in there... maybe its on purpose, which would make me wonder about quality of the project. which it seems other commenters are also debating
I think the idea is that instead of your application buying into being wrapped in Electron, your application design stays yours and you can embed Zebkit as a part, as you would SQLite or some library. Useful when you need some web-based views or PDF rendering somewhere in your app.
How much percentage of CEF code will you reuse?
The update of Chromium code is very frequent, how would you follow the conflicts after you modify it? How long time gap do you estimate you will have to follow the Chromium code? Per my experience with Browser development, too long time gap is not acceptable to users.
I'm pretty impressed on the sophisticated agentic engineering side of it, what is your methodology in using Claude, say like what is your initial prompt and the thinking process? Any recommended skills or plugins?
49 comments
[ 3.9 ms ] story [ 51.0 ms ] threadThe project is very interesting and opens up a lot of use cases - like a replacement for JSDOM in UI testing, a replacement for puppeteer/playwright in e2e testing, or even a base to build a single binary web browser MCP.
>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 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, choice of JavaScript engine should 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)
One clarification: Zebkit still uses Chromium's sandboxed renderer processes and shared memory internally. The embedding interface is a C API: your application links the library, keeps its own window and event loop, and can either embed a web view or receive off-screen frames to draw itself.
There's no Go binding yet, but the C API should be usable through cgo. If you give it a try, I'd love to hear where it fits your setup and where the integration gets awkward. Thanks for sharing your use case!
A browser is a good choice if it fits your app! Zebkit is for embedding Chromium into a native app while keeping control of the host.
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.
Where CEF is still ahead: 1. Maturity: it's a product over decade and a big community, zebkit is rather young, but I will keep maintain it 2. platform: zebkit ships linux x64, macos sillicon and windows x64, cef covers mac intels, arm linux and many others. 3. missing pieces: zebkit has no printing, web bluetooth, wideevine and so on
Zebkit is still a young project, and I’d love to hear your feedback to help it keep improving.
For the size, I have some more to address: the real weight comes from Blink, V8, skia, network stack and media. WebRTC cannot be dropped since Blink depends on it. Video playback is need by most apps so it stays. And the webusb is small, drop it has little benefit.
The main differences are mostly from shape, not the engine: 1. Exposed as a library with bindings (rust, python, JS without node) that can be run in your application's own event loop 2. Almost everything in the engine have a hook point such as permission, network, dialog, menus .. 3. Exported Chromium's C Library (such as boringssl, zstd, ffmpeg ..) for your app so you do not need compile it or ship it twice such as ELectron. 4. Exported feature rich PDF library (pdfium with improved) 5. Playwright inside, no cdp and no node are required
Probably the two biggest user's of CEF (in terms of user base exposed to it daily) would be Steam and Spotify. Both relatively fast and efficient, compared to their peers, albeit the UX is another question.
If this gets popular, expect Google to block it too.
Yep.
My sciter[.com] dll is about 18mb on Windows which is 10 times less than zebkit (171.2 Mb). And sciter's cold start (window creation, document loading and painting) is around 60ms that is 38 times less than 2.3 seconds of zebkit.
https://github.com/zenbu-labs/terminal-browser
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
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.
And you pointed a real gap: the release archives contain no license or notice files, I will add them in next release. Thank you!
I think energies should go towards something like sciterjs, or equivalent tech, with with a small footprint gives a great cross platform DX. I recall the sciterjs author a few years ago tried to put together some donations to open source, but it didn't go through.
Electrobun was an effort recently (but that too decompresses to ~70MB). There was antjs or something, which seems to have gone nowhere. Small size, scriptable, cross platform, huge library - whoever cracks this has the platform of the future. (No wonder TUIs are doing so well.)
I notice electron apps never seem to do this.