Riiiiichard

Currently, it has been upgraded from Chrome 155 to the latest 157. I will try to keep it align with the latest chromium at best.

Thank you!

Yes, you got it.

Thanks, that's really useful coming from someone shipping CEF in production, and ZShot looks great.

And you pointed a real gap: the release archives contain no license or notice files, I will add them in next release. Thank you!

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

Yes, it has the same process sandbox features like Chromium.

Yes, I'm actively maintain this project, If you want to have go bindings, no problem.

It has the same sandbox support and limitations as Chromium. It supports X11 default in Linux and with limited Wayland support.

It has been tested on M4 macbook and works fine, if you have issues, just post it on the project.

Short version:

It packages Chromium as a library you can embed directly into applications to add browser capabilities.

It’s trimmed down to be 33% smaller than Electron, with native browser automation APIs for AI agents that run 3–10× faster than tools like Playwright operating over CDP. It also directly exposes 7,000+ functions from Chromium’s bundled libraries for your application to use.

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.

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!

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.

ConciseMark is a simplified markdown parsing library written in Rust with customization, math supporting in mind. The simplified here means it only supports some common markdown syntax but not full.

And I also update my nvim-previewer(https://github.com/ikey4u/nvim-previewer) plugin to use concisemark because I want to preview math equation which neither pulldown-cmark nor comrak supports.