5 Lightweight Alternatives to Electron

Five lightweight Electron alternatives are worth a look: tinyjs, Electrobun, Neutralinojs and Wails, which render your frontend in the operating system’s own webview, and Perry, which compiles TypeScript into a native app that draws real platform widgets and has no webview at all.

You have a React or Svelte frontend that works well, and yet the installer for a small utility built on it is bigger than most of the apps installed next to it.

Every Electron app bundles its own Chromium and Node.js, so each install carries a full browser engine and each running app pays for it in disk space and memory. This article compares five alternatives using the same four criteria: how each one renders, which language runs the backend, which desktop platforms it supports, and who it suits.

Why Do Developers Look for Electron Alternatives?

Most Electron alternatives leave Chromium out of the bundle and borrow the webview the OS already ships, which makes apps much smaller. The price is rendering consistency. Your app runs on WebKit on macOS, WebView2 on Windows and WebKitGTK on Linux, so the edges behave the way they do when you ship one site to Safari and Chrome.

Two well-known options aren’t part of the five below. Tauri pairs the system webview with a Rust backend. Deno Desktop builds desktop apps on the Deno runtime.

The table below compares the five Electron alternatives on rendering engine, backend language, desktop platforms and reported size:

tinyjs: JavaScript Backend With No Open Ports

tinyjs runs a JavaScript backend on txiki.js and shows your page in the platform’s own webview: WebKit on macOS, WebView2 on Windows and WebKitGTK on Linux. The page and the backend talk over a Unix socket (a named pipe on Windows), so the app never opens a local network port.

• Backend: txiki.js (QuickJS plus libuv), with access to files, processes, sockets, FFI and SQLite. Node isn’t needed at runtime.
• Platforms: the repo targets macOS, Windows and Linux, and the project site calls macOS the primary platform. Builds must run on the OS you are shipping for. tinyjs build produces a signed bundle and tinyjs notarize submits it for Apple notarization.
• Size: tinyjs puts a shipped app at about 6 MB. Its txiki.js runtime accounts for 5.6 MB of that.

tinyjs new myapp --template react-ts
cd myapp
tinyjs dev
tinyjs build

The backend exports an api object, and the page calls its methods by name:

// src/backend/main.js
export const api = {
  greet: async ({ user }) => `Welcome, ${user}`,
};

// in the page
const message = await tiny.api.call('greet', { user });

tinyjs warns that Linux is where rendering differs most. Media codecs depend on which GStreamer plugins are installed, and Web Audio output can crackle under WebKitGTK. Suits: JavaScript developers who want the whole app, backend included, in one language.

Electrobun: TypeScript or Compiled Main Process

Electrobun renders with the system webview by default. Its main process runs TypeScript on Cottontail (or Bun), or you can write it in Zig, Rust, Go or Odin. It targets macOS, Windows and Linux.

• Renderer: the system webview by default. You can bundle Chromium through CEF when identical rendering across platforms matters more than download size.
• Backend: Cottontail, which the 2.0 release introduces as a JavaScript runtime built with Zig on JavaScriptCore.
• Size: Electrobun reports compressed hello-world downloads on macOS ARM64 of 1.28 MiB with a native main process and about 15 MiB with Cottontail.
• Shipping: code signing, differential updates and installers for each OS are built in. The package is MIT-licensed on npm.

npx electrobun init

import { BrowserWindow } from "electrobun/main";

new BrowserWindow({
  title: "Inventory",
  url: "views://mainview/index.html",
  frame: { width: 1024, height: 720 },
});

The views:// scheme loads a bundled view from your project. If you use Electrobun’s Hutch CLI, hutch electrobun init scaffolds the same project. Suits: teams that want Electron’s main/renderer split in a much smaller package.

Neutralinojs: Page-Only Apps, No General-Purpose Backend

Neutralinojs renders in the OS webview and has no general-purpose JavaScript backend process. Your code runs in the page and calls a built-in native API. Its documentation confirms that no Chromium ships with the app. It relies on the web view the OS provides instead, such as WebKitGTK on Linux.

• Backend: the page reaches the native layer through a client library. Per the Neutralinojs GitHub repository, native calls travel over a WebSocket, and a built-in static server delivers the frontend files. For logic the API doesn’t cover, you can write extensions in any language and connect them over IPC.
• Platforms: Linux, Windows, macOS and Web. The releases page lists v6.10.0 as the latest release.

Suits: small utilities whose needs fit within the built-in API (file access, running commands, dialogs).

Perry: Native Widgets, Not a Webview

Perry is not a webview wrapper. It compiles TypeScript ahead of time through LLVM into a native executable that draws real platform widgets: AppKit on macOS, Win32 on Windows and GTK4 on Linux. Perry also targets mobile, watches and TV.

• Backend: there is no separate backend. The whole app is TypeScript compiled to machine code, with Perry’s runtime linked into the binary when the program needs it.
• Limits: Perry compiles a practical subset of TypeScript, and its limitations page rules out eval() and other dynamic code and lists only partial decorator support. Some npm packages won’t compile. For JavaScript npm compatibility, Perry offers an optional V8 runtime through --enable-js-runtime.
• Size: Perry’s repo gives about 34 KB for a hello world that only prints constants. Once a program uses the runtime (loops, JSON, async), expect a few MB, about 5.5 MB on macOS arm64.

perry doctor
perry check ./src
perry compile main.ts -o myapp

perry doctor checks that the compiler, linker and platform SDK are installed. perry check reports code that won’t compile natively. Perry has no DOM, so frontend code that depends on the DOM doesn’t carry over. Suits: TypeScript developers who are willing to rewrite the UI to get native controls.

Wails: Go Backend, System Webview

Wails pairs a Go backend with the OS webview. Go developers keep the web frontend tooling they already use, and each platform’s own WebView renders it, so no browser engine is bundled. Wails v3.0.0 shipped on 26 October 2026.

• Renderer: WebView2 on Windows and WebKit on macOS. Since v3.0.0, Linux uses GTK4 with WebKitGTK 6.0 by default, and the older GTK3 stack stays available with -tags gtk3 until v3.1.
• Status: v3.0 is the current stable line, and v2 still receives critical updates. iOS and Android support in v3 is experimental and outside the stability promise. Releases ship regularly.
• Size: the Why Wails page reports binaries of about 15 MB.

go install github.com/wailsapp/wails/v3/cmd/wails3@latest
wails3 setup

Suits: teams whose backend logic already lives in Go.

Which Electron Alternative Should You Choose?

The right Electron alternative depends first on the language you want on the backend, then on how much rendering variation you can accept. JavaScript all the way through points to tinyjs. A TypeScript main process with an optional bundled Chromium points to Electrobun. Go points to Wails, and an app that only needs a built-in native API points to Neutralinojs. If you want native controls rather than a web UI, Perry is the only option of the five. Before committing, build a hello world with your top two candidates and run your real frontend in each target OS’s webview.

FAQs

Do Windows users need to install WebView2 to run apps built with these tools?

Usually not. The Evergreen WebView2 Runtime comes preinstalled on all Windows 11 devices, and Microsoft rolled it out to most Windows 10 devices, including managed and domain-joined ones from January 2023. A small number of Windows 10 machines still lack it. Microsoft therefore recommends that your installer checks for the runtime and deploys it when it is missing, even if you use Evergreen mode.

Can I reuse an existing React frontend with Perry?

Only partly, and only experimentally. Perry has no DOM, but the separate perry-react project is a React-compatible renderer. A packageAliases block in package.json points react and react-dom imports at perry-react, and JSX elements map to native widgets, for example div to VStack and button to Button. It describes itself as a Phase 1 proof of concept that targets macOS, with iOS, Android, GTK4 and Win32 planned. In Phase 1, instances of the same component share hook state, className styling is not supported (only inline style props), and libraries that depend on the DOM or className, such as MUI or React Router, do not work.

Which of these Electron alternatives can also build mobile apps?

Perry targets mobile. It compiles the same TypeScript to iOS and Android, and also to watchOS and TV. tinyjs says it does not support iOS or Android and calls itself a desktop runtime. Neutralinojs lists Linux, Windows, macOS and Web as its platforms. Wails v3 has experimental iOS and Android support that isn't yet covered by its stability promise. If you want a webview app that also runs on phones, Tauri 2 supports iOS and Android alongside desktop.

What do Linux users need installed to run a system webview app?

They need a WebKitGTK library, because these tools use the system webview instead of bundling one. The tinyjs examples list libwebkit2gtk-4.1-0 as a Linux requirement. Wails v3.0 uses GTK4 with WebKitGTK 6.0 by default. Audio and video support depends on which GStreamer plugins the machine has, so test media playback on every Linux distribution you plan to support.