5 schlanke Alternativen zu Electron

Fünf schlanke Electron-Alternativen sind einen Blick wert: tinyjs, Electrobun, Neutralinojs und Wails rendern Ihr Frontend in der systemeigenen Webview des Betriebssystems. Perry hingegen kompiliert TypeScript zu einer nativen App, die echte Plattform-Widgets zeichnet und ganz ohne Webview auskommt.

Sie haben ein React- oder Svelte-Frontend, das gut funktioniert, und trotzdem ist der Installer für ein kleines Tool, das darauf aufbaut, größer als die meisten Apps, die daneben installiert sind.

Jede Electron-App bündelt ihr eigenes Chromium und Node.js. Damit bringt jede Installation eine vollständige Browser-Engine mit, und jede laufende App bezahlt dafür mit Speicherplatz und Arbeitsspeicher. Dieser Artikel vergleicht fünf Alternativen anhand derselben vier Kriterien: wie gerendert wird, in welcher Sprache das Backend läuft, welche Desktop-Plattformen unterstützt werden und für wen sich das jeweilige Tool eignet.

Warum suchen Entwickler nach Alternativen zu Electron?

Die meisten Electron-Alternativen lassen Chromium aus dem Bundle weg und nutzen stattdessen die Webview, die das Betriebssystem ohnehin mitbringt. Dadurch werden Apps deutlich kleiner. Der Preis dafür ist die Rendering-Konsistenz: Ihre App läuft unter macOS auf WebKit, unter Windows auf WebView2 und unter Linux auf WebKitGTK. An den Rändern verhält sie sich also so, wie wenn Sie eine Website gleichzeitig für Safari und Chrome ausliefern.

Zwei bekannte Optionen gehören nicht zu den fünf unten vorgestellten. Tauri kombiniert die System-Webview mit einem Rust-Backend. Deno Desktop baut Desktop-Apps auf der Deno-Runtime auf.

Die folgende Tabelle vergleicht die fünf Electron-Alternativen hinsichtlich Rendering-Engine, Backend-Sprache, Desktop-Plattformen und angegebener Größe:

tinyjs: JavaScript-Backend ohne offene Ports

tinyjs führt ein JavaScript-Backend auf txiki.js aus und zeigt Ihre Seite in der plattformeigenen Webview an: WebKit unter macOS, WebView2 unter Windows und WebKitGTK unter Linux. Seite und Backend kommunizieren über einen Unix-Socket (unter Windows über eine Named Pipe), sodass die App nie einen lokalen Netzwerkport öffnet.

• Backend: txiki.js (QuickJS plus libuv) mit Zugriff auf Dateien, Prozesse, Sockets, FFI und SQLite. Node wird zur Laufzeit nicht benötigt.
• Plattformen: Das Repository zielt auf macOS, Windows und Linux, und die Projektseite bezeichnet macOS als primäre Plattform. Builds müssen auf dem Betriebssystem laufen, für das Sie ausliefern. tinyjs build erzeugt ein signiertes Bundle, und tinyjs notarize reicht es zur Notarisierung bei Apple ein.
• Größe: tinyjs beziffert eine ausgelieferte App auf etwa 6 MB. Davon entfallen 5,6 MB auf die txiki.js-Runtime.

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

Das Backend exportiert ein api-Objekt, und die Seite ruft dessen Methoden über ihren Namen auf:

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

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

tinyjs weist darauf hin, dass sich das Rendering unter Linux am stärksten unterscheidet. Medien-Codecs hängen davon ab, welche GStreamer-Plugins installiert sind, und die Web-Audio-Ausgabe kann unter WebKitGTK knistern. Geeignet für: JavaScript-Entwickler, die die gesamte App einschließlich Backend in einer einzigen Sprache schreiben möchten.

Electrobun: TypeScript oder kompilierter Main-Prozess

Electrobun rendert standardmäßig mit der System-Webview. Der Main-Prozess führt TypeScript auf Cottontail (oder Bun) aus, alternativ können Sie ihn in Zig, Rust, Go oder Odin schreiben. Unterstützt werden macOS, Windows und Linux.

• Renderer: standardmäßig die System-Webview. Wenn identisches Rendering über alle Plattformen hinweg wichtiger ist als die Downloadgröße, können Sie Chromium über CEF mitliefern.
• Backend: Cottontail, das mit dem Release 2.0 als in Zig geschriebene JavaScript-Runtime auf Basis von JavaScriptCore eingeführt wurde.
• Größe: Electrobun gibt komprimierte Hello-World-Downloads unter macOS ARM64 mit 1,28 MiB bei nativem Main-Prozess und mit etwa 15 MiB bei Cottontail an.
• Auslieferung: Code-Signierung, differenzielle Updates und Installer für jedes Betriebssystem sind integriert. Das Paket ist unter MIT-Lizenz auf npm verfügbar.

npx electrobun init

import { BrowserWindow } from "electrobun/main";

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

Das Schema views:// lädt eine gebündelte View aus Ihrem Projekt. Wenn Sie Electrobuns Hutch-CLI verwenden, erzeugt hutch electrobun init das gleiche Projektgerüst. Geeignet für: Teams, die Electrons Aufteilung in Main- und Renderer-Prozess in einem deutlich kleineren Paket möchten.

Neutralinojs: Reine Seiten-Apps ohne universelles Backend

Neutralinojs rendert in der Webview des Betriebssystems und besitzt keinen universellen JavaScript-Backend-Prozess. Ihr Code läuft in der Seite und ruft eine integrierte native API auf. Laut Dokumentation wird kein Chromium mit der App ausgeliefert. Stattdessen nutzt Neutralinojs die Webview, die das Betriebssystem bereitstellt, etwa WebKitGTK unter Linux.

• Backend: Die Seite erreicht die native Schicht über eine Client-Bibliothek. Laut dem GitHub-Repository von Neutralinojs laufen native Aufrufe über einen WebSocket, und ein integrierter statischer Server liefert die Frontend-Dateien aus. Für Logik, die die API nicht abdeckt, können Sie Extensions in beliebiger Sprache schreiben und per IPC anbinden.
• Plattformen: Linux, Windows, macOS und Web. Die Releases-Seite führt v6.10.0 als aktuelles Release.

Geeignet für: kleine Tools, deren Anforderungen sich mit der integrierten API abdecken lassen (Dateizugriff, Ausführen von Befehlen, Dialoge).

Perry: Native Widgets statt Webview

Perry ist kein Webview-Wrapper. Es kompiliert TypeScript Ahead-of-Time über LLVM zu einer nativen ausführbaren Datei, die echte Plattform-Widgets zeichnet: AppKit unter macOS, Win32 unter Windows und GTK4 unter Linux. Perry unterstützt außerdem Mobilgeräte, Smartwatches und TV.

• Backend: Es gibt kein separates Backend. Die gesamte App ist zu Maschinencode kompiliertes TypeScript, wobei Perrys Runtime in das Binary gelinkt wird, wenn das Programm sie benötigt.
• Einschränkungen: Perry kompiliert eine praxistaugliche Teilmenge von TypeScript. Die Seite zu den Einschränkungen schließt eval() und anderen dynamischen Code aus und nennt nur teilweise Unterstützung für Decorators. Manche npm-Pakete lassen sich nicht kompilieren. Für die Kompatibilität mit JavaScript-npm-Paketen bietet Perry eine optionale V8-Runtime über --enable-js-runtime.
• Größe: Perrys Repository nennt etwa 34 KB für ein Hello World, das lediglich Konstanten ausgibt. Sobald ein Programm die Runtime nutzt (Schleifen, JSON, async), sollten Sie mit einigen MB rechnen, unter macOS arm64 etwa 5,5 MB.

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

perry doctor prüft, ob Compiler, Linker und Plattform-SDK installiert sind. perry check meldet Code, der sich nicht nativ kompilieren lässt. Perry hat kein DOM, daher lässt sich DOM-abhängiger Frontend-Code nicht übernehmen. Geeignet für: TypeScript-Entwickler, die bereit sind, die UI neu zu schreiben, um native Steuerelemente zu erhalten.

Wails: Go-Backend mit System-Webview

Wails kombiniert ein Go-Backend mit der Webview des Betriebssystems. Go-Entwickler behalten ihr gewohntes Web-Frontend-Tooling, und die jeweils plattformeigene WebView rendert das Ergebnis, sodass keine Browser-Engine mitgeliefert wird. Wails v3.0.0 erschien am 26. Oktober 2026.

• Renderer: WebView2 unter Windows und WebKit unter macOS. Seit v3.0.0 verwendet Linux standardmäßig GTK4 mit WebKitGTK 6.0; der ältere GTK3-Stack bleibt bis v3.1 über -tags gtk3 verfügbar.
• Status: v3.0 ist die aktuelle stabile Versionslinie, v2 erhält weiterhin kritische Updates. Die Unterstützung für iOS und Android in v3 ist experimentell und nicht vom Stabilitätsversprechen abgedeckt. Releases erscheinen regelmäßig.
• Größe: Die Seite Why Wails gibt Binaries von etwa 15 MB an.

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

Geeignet für: Teams, deren Backend-Logik bereits in Go vorliegt.

Welche Electron-Alternative sollten Sie wählen?

Die richtige Electron-Alternative hängt in erster Linie von der gewünschten Backend-Sprache ab und erst danach davon, wie viel Rendering-Abweichung Sie akzeptieren können. Wer durchgängig JavaScript möchte, ist bei tinyjs richtig. Ein TypeScript-Main-Prozess mit optional gebündeltem Chromium spricht für Electrobun. Go spricht für Wails, und eine App, die nur eine integrierte native API benötigt, spricht für Neutralinojs. Wenn Sie native Steuerelemente statt einer Web-UI möchten, ist Perry die einzige Option unter den fünf. Bevor Sie sich festlegen, sollten Sie mit Ihren beiden Favoriten ein Hello World bauen und Ihr echtes Frontend in der Webview jedes Zielbetriebssystems ausführen.

FAQs

Müssen Windows-Nutzer WebView2 installieren, um mit diesen Tools erstellte Apps auszuführen?

In der Regel nicht. Die Evergreen WebView2 Runtime ist auf allen Windows-11-Geräten vorinstalliert, und Microsoft hat sie auf die meisten Windows-10-Geräte ausgerollt, ab Januar 2023 auch auf verwaltete und domänengebundene Geräte. Einer kleinen Zahl von Windows-10-Rechnern fehlt sie dennoch. Microsoft empfiehlt daher, dass Ihr Installer das Vorhandensein der Runtime prüft und sie bei Bedarf installiert, auch wenn Sie den Evergreen-Modus verwenden.

Kann ich ein bestehendes React-Frontend mit Perry weiterverwenden?

Nur teilweise und nur experimentell. Perry hat kein DOM, aber das separate Projekt perry-react ist ein React-kompatibler Renderer. Ein packageAliases-Block in der package.json leitet react- und react-dom-Importe auf perry-react um, und JSX-Elemente werden auf native Widgets abgebildet, zum Beispiel div auf VStack und button auf Button. Das Projekt bezeichnet sich selbst als Proof of Concept in Phase 1, der auf macOS abzielt; iOS, Android, GTK4 und Win32 sind geplant. In Phase 1 teilen sich Instanzen derselben Komponente den Hook-State, Styling über className wird nicht unterstützt (nur Inline-style-Props), und Bibliotheken, die vom DOM oder von className abhängen, etwa MUI oder React Router, funktionieren nicht.

Welche dieser Electron-Alternativen können auch Mobile-Apps erstellen?

Perry unterstützt Mobilgeräte. Es kompiliert dasselbe TypeScript für iOS und Android sowie für watchOS und TV. tinyjs gibt an, iOS und Android nicht zu unterstützen, und bezeichnet sich als Desktop-Runtime. Neutralinojs nennt Linux, Windows, macOS und Web als Plattformen. Wails v3 bietet experimentelle Unterstützung für iOS und Android, die noch nicht vom Stabilitätsversprechen abgedeckt ist. Wenn Sie eine Webview-App suchen, die auch auf Smartphones läuft, unterstützt Tauri 2 neben dem Desktop auch iOS und Android.

Was müssen Linux-Nutzer installiert haben, um eine App mit System-Webview auszuführen?

Sie benötigen eine WebKitGTK-Bibliothek, da diese Tools die System-Webview verwenden, statt eine eigene mitzuliefern. Die tinyjs-Beispiele nennen libwebkit2gtk-4.1-0 als Voraussetzung unter Linux. Wails v3.0 verwendet standardmäßig GTK4 mit WebKitGTK 6.0. Die Audio- und Videounterstützung hängt davon ab, welche GStreamer-Plugins auf dem Rechner vorhanden sind. Testen Sie die Medienwiedergabe daher auf jeder Linux-Distribution, die Sie unterstützen möchten.