Die App, die ihren eigenen Browser mitbringt
Das Kernproblem von Electron ist einfach: Jede App bringt ihren eigenen Browser mit. Es bündelt Webtechnologien (HTML, CSS, JavaScript) mit Node.js.js für die Interaktion mit dem System und verpackt alles in eine dedizierte Chromium-Runtime. Diese Architektur bedeutet, dass jede Electron-App eine in sich geschlossene Webumgebung ist, unabhängig vom nativen Browser des Betriebssystems.
Dieses Design fordert einen hohen Tribut an Systemressourcen. Nehmen Sie Claude unter macOS: Allein das Electron Framework belegt 286 MB der insgesamt 618 MB der App. Auf einem Mac machten 22 Electron-Apps zusammen 6,5 GB an doppelten Chromium-Kopien aus. Jede Chromium-Instanz benötigt zudem Arbeitsspeicher; Claude nutzte allein im geöffneten Zustand etwa 600 MB RAM, verteilt auf 11 Prozesse.
Diese Zahlen stammen aus einem Video von Better Stack und veranschaulichen die Belastung. Wichtig ist: Es handelt sich um konkrete Beispiele, nicht um allgemeingültige Benchmarks. Die endgültige Größe und der Speicherbedarf einer App schwanken erheblich je nach gebündelten Tools, verwendeten Bibliotheken und aktueller Auslastung, doch die zugrunde liegende Ineffizienz isolierter Chromium-Instanzen bleibt bestehen.
Warum die Alternativen kein kostenloser Gewinn sind
Kritiker von Electron führen native Entwicklung oft als naheliegende Alternative an, doch dieser Weg ist mit vervielfachtem Aufwand gepflastert. Die Entwicklung mit SwiftUI für den Mac bietet zwar eine pixelgenaue Erfahrung, erfordert aber völlig separate Implementierungen für Windows und Linux, was den Entwicklungs- und Wartungsaufwand drastisch erhöht. Ein Unternehmen, 1Password, benötigte einst vier getrennte Teams, bevor es sich auf Electron konsolidierte.
Alternativen wie Tauri und Wails begegnen dem Ballast von Electron, indem sie die vorhandene Webview des Betriebssystems nutzen – WebKit unter macOS, WebView2 unter Windows, WebKitGTK unter Linux –, während Rust oder Go die nativen Systeminteraktionen übernehmen. Dieser Ansatz liefert deutlich leichtere Apps: Eine leere Tauri-App wiegt auf dem Mac etwa 5 MB, verglichen mit der typischen Basis-Runtime von Electron mit 268 MB.
Diese Effizienz bringt jedoch einen entscheidenden Kompromiss mit sich: die Kompatibilität. Wer auf System-Webviews setzt, muss damit rechnen, dass das Rendering der App je nach Plattform variiert und Fehler oder Inkonsistenzen auf Betriebssystemebene übernommen werden, auf die Sie keinen Einfluss haben. Slack nutzte beispielsweise ursprünglich die in macOS integrierte Safari-Engine, wechselte aber zu Electron, nachdem in älteren macOS-Versionen nicht behebbare Rendering-Probleme aufgetreten waren.
Letztlich geht der scheinbar „kostenlose Gewinn“ leichterer Alternativen zulasten von Konsistenz und Kontrolle. Tauri und Wails bieten zwar beeindruckende Größenreduzierungen, führen aber genau die Fragmentierung wieder ein, die Electron überwinden sollte, und zwingen Entwickler dazu, Performance und vorhersehbare Benutzererfahrung gegeneinander abzuwägen.
Konsistenz schlägt Eleganz im großen Maßstab
Die wahre Stärke von Electron und zugleich sein ärgerlichster Makel liegt in seiner Eigenständigkeit. Während native Apps auf unberechenbare System-Webviews setzen – etwa die Safari-Engine unter macOS oder die von Edge unter Windows –, bündelt Electron seine eigene Chromium-Runtime. Das garantiert eine konsistente Rendering-Umgebung unter Windows, macOS und Linux und erspart Entwicklern plattformspezifische Überraschungen.
Diese Kontrolle hat jedoch ihren Preis. Als Slack zunächst auf die in macOS integrierte Safari-Engine setzte, waren sie bei älteren Betriebssystemversionen mit Safari-Fehlern machtlos. Der Wechsel zu Electron verschaffte ihnen eine einheitliche Codebasis und die Autonomie, Fehlerbehebungen selbst auszuliefern. Dieser Kompromiss ist der Grund, warum selbst neuere Frameworks wie Tauri erwägen, Chromium zu bündeln, und damit die Kernstärke von Electron anerkennen. Mehr über die Möglichkeiten erfahren Sie unter Electron: Build Cross-Platform Desktop Apps.
Diese Autonomie führt jedoch zu einem weitverzweigten Update-Problem. Jede Electron-App enthält ihre eigene Chromium-Kopie. Eine Korrektur an Electron oder Chromium selbst erreicht die Nutzer daher erst, nachdem jeder einzelne App-Anbieter ein Update veröffentlicht hat. So verursachte beispielsweise ein macOS-Update im vergangenen Jahr systemweite Verzögerungen in Electron-Apps, weil ein Electron-Fehler privaten Apple-UI-Code überschrieb. Die Korrektur musste von jeder einzelnen betroffenen App weitergegeben werden, was die enorme Ineffizienz dieses verteilten Update-Modells verdeutlicht. Dieser Ansatz, der Konsistenz über Eleganz stellt, vereinfacht zwar die Entwicklung, fragmentiert aber die Benutzererfahrung.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Bei KI-Apps kann eine Codebasis drei schlagen
Für schnelllebige KI-Produkte ist der Reiz von Electron unbestreitbar. Gemeinsamer Web- und Desktop-Code ermöglicht es Teams, Funktionen mit weniger doppeltem Aufwand auf Mac, Windows und Linux zu übertragen und die Entwicklung von Produkten wie Anthropic’s Claude und OpenAI’s Codex zu straffen. Dabei handelt es sich um technische Abwägungen, nicht um pauschale Empfehlungen für Electron.
OpenAI ersetzte beispielsweise seine native ChatGPT-Mac-App durch einen Electron-basierten Codex-Client. Während die ursprüngliche native App 159 MB groß war, wuchs die neue Electron-Version auf 1,7 GB – wobei ein erheblicher Teil auf gebündelte Codex-Tools entfällt. Das verdeutlicht die Ressourcenkosten einer einheitlichen Codebasis.
Selbst mit fortschrittlichen KI-Coding-Tools verschwindet die Last nativer Clients nicht. Coding-Agenten sind stark darin, erste Implementierungen zu erzeugen, doch das Testen, Korrigieren und Unterstützen mehrerer plattformspezifischer Apps bleibt eine erhebliche Herausforderung und vervielfacht die Zahl der Fehler und den Wartungsaufwand. Wie einer der Entwickler von Claude Code sagte: „Drei Apps, das sind dreimal so viele Fehler, die behoben und betreut werden müssen.“
Die praktische Faustregel lautet weiterhin: Für kleine Hilfsprogramme, bei denen der Platzbedarf zählt, sollten Sie Tauri oder Wails in Betracht ziehen, die unter macOS Apps mit nur 5 MB erzeugen können. Für komplexe, plattformübergreifende Produkte, die auf konsistentes Verhalten und schnelle Releases auf Mac, Windows und Linux Wert legen, bleibt Electron die sicherere und besser vorhersehbare Wahl.
Häufig gestellte Fragen
Warum benötigen Electron-Apps so viel Arbeitsspeicher?
Jede Electron-App bündelt Chromium und führt eigene Prozesse aus, was auch im Leerlauf der App zusätzlichen Overhead verursacht.
Warum entscheiden sich Unternehmen weiterhin für Electron?
Es bietet eine konsistente Chromium-Umgebung und ermöglicht es Teams, Code auf Mac, Windows, Linux und oft auch im Web gemeinsam zu nutzen.
Ist Tauri immer kleiner als Electron?
Die App-Bundles können deutlich kleiner sein, da Tauri in der Regel die Webview des Betriebssystems verwendet, das Rendering kann jedoch je nach Plattform variieren.
Wann sollte ein Team auf native Entwicklung setzen?
Nativ kann eine gute Wahl sein, wenn plattformspezifische Performance und Benutzererfahrung den Aufwand für separate Implementierungen rechtfertigen.