Home
AI
Blog

Electrobun: No Node, No Chromium, Pure Bun Performance

basanta sapkota

Electron apps are handy… until you ship a “hello world” and the download size looks like you accidentally packed a small operating system in there. Been there. If you’ve ever had to defend bundling Chromium and Node just so your app can display a settings screen, Electrobun is the kind of project that makes you sit up a little straighter.

Electrobun is a cross-platform desktop app framework built around Bun and native system webviews. The project’s big promise, straight from its own “No Node, No Chromium” talk, is apps up to ~6× smaller than Electron while keeping performance in that “feels native-ish” zone. And honestly, the choices behind it feel… practical. Refreshingly so.

Key takeaways

Here’s the stuff people actually care about:

  • The main process runs on Bun, not Node, and Electrobun uses native bindings written in Zig.
  • You don’t have to ship Chromium by default. It can lean on the system webview for smaller builds, and you can still bundle a browser runtime when you need consistency.
  • Small bundles aren’t a fantasy. The GitHub README cites ~12MB self-extracting app bundles when using the system webview, and most of that is basically the Bun runtime.
  • Updates can get comically tiny. Electrobun advertises patches as small as ~14KB using bsdiff-style binary diffs.
  • If you’ve shipped Electron, you won’t feel lost. You still get the usual lineup: windows, menus, tray, events, updater… the whole deal.

What even is Electrobun?

At the 30,000-foot view, it’s kind of “Electron, but swap out the heavy suitcase for a carry-on.”

Electron typically ships:

  • Chromium for rendering
  • Node for runtime
  • Your app on top

Electrobun instead ships:

  • Bun
  • native bindings
  • your UI rendered through the system webview

The repo calls it a “complete solution-in-a-box” for building, updating, and shipping desktop apps written in TypeScript. Bun runs the main process and handles bundling webview code. Zig handles the native bindings. That combo is the whole point: you get the “small app, fast build” story without being told, yet again, to rewrite your app in Rust or C++.

If you want the official, straight-from-the-source version, start here: https://blackboard.sh/electrobun/docs/

Why “no Chromium” changes the bundle-size game

Bundling Chromium is the classic Electron bargain. You get consistent rendering everywhere.But also get big artifacts and often-noticeable RAM use. Pick your poison.

Electrobun can skip shipping a browser and use whatever webview the OS already provides:

  • Windows uses Microsoft’s WebView2 Runtime. It’s Chromium-based, but crucially it’s managed at the OS level instead of being dragged into your installer.
  • macOS uses Apple’s WebKit stack via WKWebView.
  • Linux usually lands on WebKitGTK, which is where things can get… “okay, but what’s installed on this machine?” real fast.

InfoWorld’s first look says an Electrobun “hello world” download without bundling a browser is generally around 30MB compressed. They also point out the obvious trade-off. Linux packaging can be messy, and if you need guaranteed behavior across machines, you may choose to bundle a browser anyway. Bigger footprint, fewer surprises. Source is InfoWorld.

One more practical detail: the Electrobun README claims ~12MB self-extracting bundles when you stick with the system webview. So yes, it can get really small. Real-world size still depends on platform packaging, compression, and whether you ship a browser runtime.

Electrobun + Bun and the “pure Bun performance” angle

Bun isn’t just “a runtime.” It’s tooling too. The bundler, bun build, is built-in and fast, and it can handle TypeScript/TSX without you building a tiny cathedral of config files first. People on Hacker News keep pointing at this part for a reason. Bun smooths out a bunch of the day-to-day friction, and Electrobun leans into that.

Authoritative reference for the bundler: https://bun.com/docs/bundler

So when you hear “pure Bun performance,” don’t picture magic. Picture a few grounded things:

  • fewer heavyweight binaries shipped with every app
  • a runtime optimized for speed
  • a simpler pipeline where TypeScript is first-class and bundling isn’t a separate side quest

Getting started

This is the basic flow described in InfoWorld and mirrored in the docs:

# install bun first, then:
bun install electrobun

# scaffold a project
bunx electrobun init

# run in dev
bun start

# build artifacts
bunx electrobun build --env=stable

Minimal main-process window example from the docs:

import { BrowserWindow } from "electrobun/bun";

const win = new BrowserWindow.

That views://... scheme is how Electrobun resolves bundled assets and views. One of those small decisions that saves you from writing your own weird plumbing at 1 a.m. Because “it’ll only take an hour.” Sure it will.

A quick note on RPC

One of the more underrated ideas here is the isolation between the main process and the webview processes, plus typed RPC between them, as described in the GitHub README.

In practice, it nudges you toward a cleaner setup:

  • UI stays UI in the webview
  • privileged work stays in the main process
  • messages are structured instead of turning into “random postMessage everywhere”

I’m biased toward this pattern. Mostly because I’ve shipped the other kind. Rushed Electron apps with IPC that slowly turns into pasta. No judgment. Just… lessons learned.

Updates and the differential patch trick (the ~14KB thing)

Desktop apps aren’t “ship it and forget it.” You’ll be shipping fixes forever. Tiny ones, silly ones, urgent ones.

Electrobun includes an update system and advertises updates as small as ~14KB, using binary diffing (bsdiff) so users download only what changed between versions, according to the GitHub README. InfoWorld highlights this too: you don’t have to bolt on your own updater, and you don’t have to push multi-megabyte patches just to fix a typo-level bug.

There is a limitation, also from InfoWorld: patches apply when upgrading from the immediately previous version. If you’re jumping versions, it falls back to downloading the full build. Reasonable trade. Keeps the patch logic simpler and avoids weird multi-hop upgrade problems.

When Electrobun is a great fit… and when it’s not

Electrobun really shines if you want Electron-like ergonomics but you actually care about installer size. And if your UI is already web tech, React/Svelte/Vite and friends, it’s a pretty natural match. No “surprise, learn Rust first” detour.

But. It’s not a universal win.

If you need pixel-identical rendering across every platform every single time, you may end up bundling a browser anyway. Linux can also be a headache depending on the target environment, especially with WebKitGTK dependencies. And if what you’re building should truly be native UI, Qt/SwiftUI/WinUI, and you already know that in your bones… you probably shouldn’t fight it.

One HN-linked writeup put it nicely: Electron isn’t really a rendering engine. It’s a bundler that brings Chromium and Node along for the ride. Electrobun picks a different ride.

If your UI stack is already web-first, Electrobun pairs naturally with modern front-end tooling. I’ve also been keeping an eye on the Vite ecosystem and platforms orbiting around it. Worth a look.
Internal link: https://www.basantasapkota026.com.np/2026/03/new-cloud-platform-by-vite-whats.html

Conclusion

Electrobun feels like a pragmatic answer to a question lots of us have asked out loud: can we keep the web-dev workflow, but stop shipping a whole browser engine every time?

Between Bun as the runtime, system webviews instead of bundled Chromium, and differential updates, the whole project is tuned for smaller artifacts and a tighter dev loop.

If you’ve got an Electron app that feels overweight, it’s honestly worth prototyping the same UI in Electrobun and measuring real stuff. Artifact size, cold start, update size. And if you do try it, I’d genuinely love to hear what broke and what got better. Drop a comment with your platform and stack.

Sources

Post a Comment