Zebkit links Chromium's engine into your app like a library, not a runtime
Zebkit – Chromium as an embeddable library
Zebkit packages Chromium 157 — Blink, V8, PDFium, FFmpeg and more — as a single library you link into your own C, C++, Rust, Python or JavaScript program. It keeps your process, event loop and toolkit, unlike Electron's runtime. The project claims a 34% smaller footprint than Electron 45.2.1, a 2.3-second cold start versus 6.6, 29% less memory per page, and native Playwright automation that is 3 to 10 times faster than over CDP.
Electron is a base: an application is built inside it, on its runtime, its windows and its packaging. zebkit is a part: an application adds it, as it adds SQLite, and keeps its process, its toolkit and its way of shipping.
- torginus
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.
- 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
- netshade
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.
- saidnooneever
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
- 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!