Roadmap

The road to beta.

Electron minus Chromium, powered by Bun and WebKit, with native modules that never need a compiler. Below: what has shipped, what we are building right now, and what beta has to prove before we use the word. If it isn't built, it says so.

v0.1.0-alpha.8 macOS · Linux · Windows MIT

Where we are today

21
Electron-shaped modules
~70-80%
weighted API parity
~1,600
tests passing · 3-OS CI matrix
0
compiled native code

On npm as 0.1.0-alpha.8; this site is the docs. It runs on macOS, Linux and Windows (x64). The CLI, the renderer build, signed auto-updates and the pinned-engine store are in place, and one hosted engine is live on the feed. The per-method truth lives on the parity page.

Release plan

From here to a beta you can check.

  1. alpha.5
    Shipped

    The first npm release

    three platforms, honest gaps, on npm.

    • The Electron-shaped API on Bun and WebKit: 21 main-process modules, roughly 70-80% of what a typical app touches, pure bun:ffi, zero compiled native code, zero runtime dependencies.
    • macOS and Linux in full. Windows (x64) in beta on a from-source WinCairo WebKit backend, green on CI next to the other two.
    • The CLI loop, init / dev / build, producing real .app, .deb and .exe distributables, and the pinned-WebKit engine store: side-by-side, content-addressed, signature-verified.
    • Frameless windows, bundled preloads, and an event-driven macOS run loop that idles at about a tenth of the CPU.
  2. alpha.6
    Shipped

    Foundation. Unglamorous on purpose.

    the fixes and plumbing everything after it stands on.

    • Crash-class fixes from our own code review: a Linux multi-window SIGSEGV and a macOS window use-after-free. Plus a security fix: a signed engine can no longer install under a different pinned id.
    • The engine feed went live at engines.bunmaska.org, Windows first, because Windows is the one platform that needs a hosted engine. bunmaska engine install verifies the Ed25519 signature and the content hash before it extracts anything.
    • Trusted input on Windows (webContents.sendInputEvent), loadFile with { hash, query, search }, one shared WebKit context on Windows so a login carries across windows, and smaller Windows binaries.
    • A test-budget gate in CI: a suite that silently stops registering now fails the build instead of shrinking quietly.
  3. alpha.7
    Shipped

    The dev loop, rebuilt. Updates you can ship.

    the release before this one.

    • Bunmaska owns the renderer build. A renderer block in the config makes dev rebuild and live-reload a React edit instead of restarting the app, and build ships the bundle beside the executable on all three OSes.
    • A dev loop that respects your saves: changes are content-hashed, atomic editor saves are never lost, a restart waits for the old process to exit, preload edits restart, the engine pin is honored, and the window comes back where you left it.
    • Signed auto-updates end to end: bunmaska keygen, a detached Ed25519 .sig from build --update, https-only feeds, unsigned updates refused, a real swap-and-relaunch quitAndInstall, and a --notarize that submits and staples.
    • API depth: session.cookies on macOS and Linux, capturePage on Linux, real macOS window geometry with a move event, setApplicationMenu(null), Super as Cmd in accelerators, and named bunmaska/electron exports.
    • What did not ship: the stable-train hosted engine. The feed has been live since alpha.6 with one engine on it; the catalogue is alpha.9 work.
  4. alpha.8
    Shipped

    Docs versus reality. Reality lost three rounds.

    the current release. `npm i bunmaska` gets you this.

    • Every claim in the docs was checked against the code, per platform, and whichever side was wrong got fixed. A new errors page, a reconciled parity table, and a CLI reference that matches --help.
    • Three real bugs the pass flushed out: a will-quit veto left the app alive with a dead run loop; build ignored name, id and icon in the config; a dev restart stole focus from your editor on every save.
    • The small things you hit first: bunmaska init my-app ., --help, a "run bun install" message instead of a stack trace, Linux builds named for the host architecture with the app version in the .deb, maximize events on macOS, silent notifications on Linux, template tray icons on macOS.
    • Bun 1.4: developed and tested on 1.4.2 on all three OSes. The engine-native bun:ffi needed one typing shim and no code changes. Packaged apps now ship production React; dev keeps the development runtime.
    • What did not ship: the React starter and the stable-train engine. Both moved to alpha.9 so that this batch of fixes reaches you now.
  5. alpha.9
    In progress

    The engine catalogue, a React starter, the last API stretch

    what we are building now. The feed itself has been live since alpha.6; what it serves is the work.

    • The catalogue, honestly. The feed serves exactly one engine today, a development-train WinCairo build we grandfathered in; our own rule is to host only stable-train releases. Three attempts to build that stable engine in CI were cancelled at the six-hour runner cap. Pack, sign and publish all work; the build needs a bigger box or a compile cache.
    • A bunmaska init --react starter on top of the alpha.7 renderer build: an IIFE bundle (file:// blocks ES modules), live reload, and the renderer shipped beside the executable. The recipe is proven in a real app; the template is the work.
    • The hosted Linux engine: the relocatable build loads from the store today. Next it has to draw, then get a cross-distro base and a publish step of its own.
    • Engine delivery you never type: embedded in the bundle, or fetched on first run.
    • The parity cells still marked easy: powerMonitor idle and battery, page-title-updated, per-instance webContents.ipc, session.clearStorageData on Linux.
    • A self-pipe wakeup primitive that structurally removes the one hang class we have ever shipped, and a worked serial-port native module published as a real package: the buildless-FFI demo, not a slide.

    Exit test a fresh machine goes install > init > build > running app on a pinned engine, on all three OSes, and no "easy" cells are left on the parity page

  6. v0.2.0-beta.1
    The bar

    What beta means here: checkable, not vibes

    every box below can be verified by you. No box, no beta.

    • The API surface is frozen for the beta line and semver discipline begins.
    • install > init > dev > build > launch runs end to end in CI on macOS, Linux and Windows, not just unit-green.
    • Stable-train engines are hosted for Windows and Linux, and the auto-updater has shipped a real update to a real app.
    • At least five real open-source Electron apps run via dependency swap, and one app we use daily has run for two weeks without a crash.
    • Docs are complete: every implemented method documented, the parity matrix exact, the migration guide tested against a real app.
    • Coverage at threshold, zero silent skips, and published size and memory numbers with the methodology attached.
  7. v1 line
    After beta

    After beta

    real, but not next. Listed so you know we know.

    • Windows ARM64 (waiting on upstream WinCairo) and a Windows isolated content world.
    • The macOS pinned-engine spike. System WKWebView stays the default either way.
    • Delta updates, crash reporting, and a SECURITY.md with a disclosure process.
    • The event-driven run loop on Linux and Windows, then upstreaming a Bun event-loop API so the pump disappears entirely.

The one everyone asks about

Windows, the honest version.

Windows is in beta - a from-scratch Win32 backend with WinCairo WebKit, green on CI. Here's the honest state, gaps and all.

Not WebView2

The easy Windows path is WebView2 - Microsoft Edge, i.e. Chromium. We didn't take it. Windows renders on WinCairo WebKit, the real WebKit port, loaded from the same engine store as every other platform.

A real Win32 backend

Built from scratch on bun:ffi - window + message pump, the WinCairo WebKit view and IPC bridge, and the full secondary-module set (clipboard incl. images, dialogs, tray, safeStorage via DPAPI, screen, shell, shortcuts, power, theme). It runs on a windows-latest CI runner.

x64 today, ARM64 next. Never 32-bit.

x64 is in beta now; ARM64 waits on upstream WinCairo. Windows is moving to ARM - so ARM64 is a when, not an if. x86 isn't on the list at all.

Still the expensive platform

Windows has no system WebKit, so we ship and maintain the WinCairo engine ourselves - CVE treadmill and all. That's why the engine feed exists: a Windows app fetches its signed engine from engines.bunmaska.org, and tracking WPE's stable train there is the alpha.9 stop.

Honest status: the backend is built and runs on a Windows CI runner, and the hosted WinCairo engine installs from the real feed end-to-end. What is still open is the stable-train build of that engine and ARM64 - both on the roadmap above. Linux is one step behind: its relocatable engine loads from the store but is not hosted yet.

Want to watch it happen?

It's all in the open. Star it, read the docs, or come argue about the parity matrix.

Read the docs Star on GitHub