Electrobun: TypeScript desktop apps on Bun, with system webviews, binary-patch updates and an optional bundled Chromium

Hutch is the front door, and it arrives through a piped install script

Electrobun projects start with Hutch, the native build and workspace CLI. On macOS or Linux it installs with a shell script:

curl -fsSL https://artifacts.electrobun.dev/hutch/install.sh | sh

On Windows PowerShell the equivalent is:

& ([scriptblock]::Create((irm https://artifacts.electrobun.dev/hutch/install.ps1)))

You then open the template picker. If `hutch` is not found, restart your terminal first.

hutch electrobun init

Both install routes download a script and run it immediately, so you are trusting artifacts.electrobun.dev with your shell. If that is not acceptable on a work machine, the alternative is to skip Hutch at the start and use an existing toolchain:

bunx electrobun init
# or
npx electrobun init

Either way you choose a template and then follow the Quick Start at docs.electrobun.dev to run the app. Hutch also manages the SDKs and toolchains needed to build templates, so skipping it moves that job back onto you.

Hutch resolves npm packages itself unless hutch.config.ts says otherwise

Package management in an Electrobun project is not tied to the runtime. By default, Hutch's built-in npm-compatible resolver installs JavaScript dependencies and writes a `hutch.lock` file. Project-local package binaries run through `hutch pm exec`.

A project's `hutch.config.ts` can override that and select npm, Bun, pnpm, Yarn or a custom executable. When it does, Hutch delegates package operations to that explicit choice. This choice is independent of whether the app's main process runs on Bun or on Cottontail.

The practical consequence is a lockfile decision you should make on purpose. A team that already standardises on pnpm or Yarn will want to set that in hutch.config.ts early, otherwise the first install produces a hutch.lock that the rest of their tooling does not read. The Hutch guide on docs.electrobun.dev covers project configuration and version management, including how Hutch pins the toolchains each template needs.

Bun runs the main process, with Cottontail as an experimental alternative

Electrobun's architecture separates three layers. Bun is the default JavaScript runtime for the main process. Cottontail is an experimental alternative runtime built on JavaScriptCore. Underneath both, the platform layer combines Zig, Objective-C and C++. The headline also says apps can be built with TypeScript, Zig, Rust, Go or Odin, though TypeScript is the language the rest of the tooling centres on.

The project goals describe what this buys you: TypeScript for both the main process and the webviews without having to think about it, and process isolation between main and webview with fast, typed RPC that is easy to implement. That typed RPC is the bridge where an Electrobun app's own logic crosses from the UI into native capabilities.

The limitation is that Cottontail is labelled experimental. If you pick it to avoid Bun, you are on the least settled part of an already beta stack. For production work, Bun is the path the project treats as the default, and the rest of the docs assume it.

System webviews keep bundles small; bundleCEF trades size for consistency

Electrobun's small bundles depend on using the system webview. One project goal is small self-extracting app bundles when the system webview is used, and the bundles themselves use Zstandard compression.

The cost of the system webview is that your UI renders in whatever engine the operating system provides, which can differ between machines. For teams that need identical rendering everywhere, Electrobun offers a `bundleCEF` flag that bundles and pins Chromium. The project frames this plainly as a trade of consistency over file size: turn it on and you gain a fixed engine, but you give up the compact downloads that are a main reason to choose Electrobun.

This decision is worth making before you build much UI. An app designed and tested against a bundled Chromium may depend on behaviour that a system webview handles differently, and switching back later means retesting across platforms. CEF.md at the repository root is the place to read about the Chromium option before you decide.

Updates ship as binary patches before falling back to full downloads

Electrobun treats updating as part of the framework rather than something you add later. Its goal is small updates that use binary patches first and fall back to a compressed full download when a patch cannot be applied.

The patches come from a Zig-optimised BSDIFF implementation that can produce kilobyte-scale updates. Full distributables are self-extracting bundles compressed with Zstandard. Together these target the stated aim of starting to write code in 5 minutes and distributing in 10.

For developers shipping frequent releases, this is the most concrete advantage: users download the difference between versions rather than the whole app. The patch size depends on what changed, though. Enabling `bundleCEF` puts a full Chromium inside the app, and the kilobyte-scale figure is the best case of the BSDIFF path, not a guarantee for every release. The documentation at docs.electrobun.dev has the API references for wiring updates into an app.

bundleWGPU draws native GPU surfaces without a webview

Not every Electrobun window has to be a webview. The `bundleWGPU` option lets TypeScript running in Bun control a native GPU surface through WGPU, with no webview involved. Three.js and Babylon.js adapters work directly in the Bun main process, so 3D code can render from the main process rather than inside a page.

Two custom HTML elements bring these pieces into a normal UI. `<electrobun-webview>` composites an isolated webview into your interface, and `<electrobun-wgpu>` does the same for a native GPU surface. That lets one window mix web content with GPU-rendered regions.

The project's own DOOM demo, blackboardsh/electrobun-doom, shows the range: it implements DOOM two ways, once as C DOOM running through bundled WGPU from Bun, and once as a full TypeScript port rendering through bundled WGPU. For most apps this is an optional path; for games, visualisations or editors with heavy rendering it is a reason to look at Electrobun over a webview-only framework.

Every recent release is a 2.0.6 beta tag

Electrobun is moving quickly. The last push was on 2 November 2026, and the three most recent releases are v2.0.6-beta.2 on 29 October, v2.0.6-beta.9 on 30 October and v2.0.6-beta.10 on 2 November 2026. A BETA_RELEASE.md file sits at the repository root alongside BUILD.md, CEF.md and CONTRIBUTING.md.

A beta cadence measured in days has a direct consequence for anyone shipping an app: behaviour can change between tags you install a few days apart. Electrobun's own mitigation is that published templates record the Electrobun version they were tested with, and Hutch handles version management. Keep that pin, and upgrade deliberately rather than by default.

Electrobun is a desktop framework. Its install scripts cover macOS, Linux and Windows, and Dash, the project's IDE built with Electrobun, builds and tests on connected Mac, Windows and Linux machines. Developers looking for Android or other mobile targets should look elsewhere.

Dash and the app list show what people already ship

The strongest evidence for Electrobun is the software built on it. Dash, the project's own general-purpose IDE, is built with Electrobun and keeps code, terminals, Git, scripts and coding agents together. The README's list of apps built with Electrobun runs from Audio TTS, a text-to-speech app using Qwen3-TTS, to dotlock for managing .env files on macOS, Dictate for Windows dictation, electrobun-pdf for local PDF and DOCX editing, the FLACK audio player for Windows, and electrobun-rms, a template with React, Tailwind CSS and Vite.

That list is useful in a specific way: it shows Electrobun used across macOS-only, Windows-only and cross-platform apps, and with front-end stacks like React and Vite. If you are wondering whether your UI framework works, the published templates and the templates/ directory in the repository are the place to check, along with the kitchen/ directory at the root.

Editorial conclusion

Electrobun fits TypeScript developers who want small desktop bundles, typed RPC between main and webview processes, and tiny binary-patch updates, and who are comfortable building on Bun and on a beta release line. It fits poorly for teams that need a settled stable version or mobile targets, or that cannot accept rendering differences between system webviews unless they turn on bundleCEF and accept larger downloads. Before committing, pin the exact Electrobun version your template was tested with, decide early between the system webview and bundleCEF, and read the Hutch guide so you know which package manager your project will use.

Frequently asked questions

Official sources

1. blackboardsh/electrobun on GitHub
2. License: MIT
3. Project website
4. README
5. Releases