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.

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

> 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.

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.

> 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.

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

Simple: this is slop, CEF is not.