Roadmap
Where this is actually going.
The goal: an Electron-class developer experience that ships tiny apps on WebKit instead of a bundled browser - with native modules that don't need a compiler. Here's what's done, what's next, and the parts we're deliberately taking slowly. No vapor; if it isn't built, it says so.
Where we are today: the framework works on macOS and Linux, the pinned-engine store and CLI are in place, and a self-contained, relocatable WebKit can be built and loaded from the store. The next milestone is hosting those engines and going public on npm.
The framework + the engine store
macOS + Linux. Alpha, and we'll admit it.
- An Electron-shaped API on Bun + WebKit - ~70-80% parity, macOS and Linux.
- Buildless native modules: a .ts file that dlopens the OS. No node-gyp. No rebuild. Ever.
- The CLI - init / dev / build - producing real .app and .deb distributables, plus a pure-Bun auto-updater.
- The pinned-WebKit engine store: side-by-side, content-addressed, signature-verified installs - the "tested == shipped" tier.
- A self-contained, relocatable WebKit you can pin and ship - its full dependency closure travels with it, loaded from the shared store.
The road to public
everything between here and `npm i bunmaska`.
- Host the prebuilt engines on a signed CDN (Cloudflare R2 - zero egress fees on big binaries).
- The render pass for the relocatable engine: it loads today; next it draws.
- Publish the first bunmaska to npm; bunmaska.org goes live.
- Starter boilerplates - React + Tailwind + Bunmaska, ready to clone.
Depth + macOS pinning
- Fill the API gaps: session.cookies, BrowserWindow setters, richer webContents events.
- Cross-distro engine builds (an old-glibc base, so one build runs across distros).
- A pinned macOS engine - opt-in, after a notarization spike. System WKWebView stays the default.
- Engine delivery to end users: embed-in-bundle, or fetch-on-first-run. Never something the user types.
Windows
deliberately last - and on our terms.
- A from-scratch Win32 backend (~5k LOC - the real work, and it's the same regardless of engine).
- WinCairo WebKit, brought via the same engine store. Never WebView2 - that's Chromium.
- ARM64 + x64 only. Never 32-bit.
The one everyone asks about
Windows, the honest version.
We're not on Windows yet, and we're not going to fudge why. It's a deliberate choice, and the reasoning is worth stating plainly.
Not WebView2
The easy Windows path is WebView2 - which is Microsoft Edge, i.e. Chromium. Shipping that would break the one promise the whole project is built on. So that door is closed on purpose.
WinCairo, brought along
Windows ships no system WebKit (Safari for Windows died in 2012). So unlike mac and Linux, we can't borrow one - we bring WinCairo WebKit through the same engine store as the pinned tier.
ARM64 + x64. Never 32-bit.
Windows is moving to ARM (Snapdragon X, Copilot+ PCs, NVIDIA's 2026 laptops). ARM64 + x64 covers the present and the future; x86 is not on the list.
It's the most work, not the least
There's no Win32 backend yet (~5k lines), and we'd own the WinCairo build + its CVE treadmill forever. Windows is the expensive platform - so it goes last, once macOS + Linux are solid.
Need Windows today? Use Electron for that target, and check back here. We'd rather ship two platforms that work than three that sort of do.
Want to watch it happen?
It's all in the open. Star it, read the docs, or come argue about the parity matrix.