Wer genügend Zeit auf Hacker News oder Reddit verbringt, stößt irgendwann auf dieselbe Kritik: Electron ist aufgebläht, Electron verbraucht zu viel Arbeitsspeicher, und ernstzunehmende Desktop-Anwendungen sollten nativ sein.
An dieser Kritik ist etwas dran. Electron-Anwendungen haben in der Regel einen höheren Grundbedarf an Ressourcen, weil sie Chromium und Node.js mitliefern. Eine sorgfältig entwickelte native Anwendung kann weniger Arbeitsspeicher benötigen, schneller starten und sich tiefer in ihr Betriebssystem integrieren.
Doch diese Debatte konzentriert sich zu sehr auf den Computer und zu wenig auf das Unternehmen, das die Software entwickelt.
Für die meisten Nutzer spielt die Technologie hinter einer Anwendung kaum eine Rolle. Ihnen ist wichtig, ob sie funktioniert, ob sie sich reaktionsschnell anfühlt, ob Fehler behoben werden und ob regelmäßig nützliche Funktionen hinzukommen. Für ein Softwareunternehmen ist eine der wichtigsten Eigenschaften eines Technologie-Stacks deshalb etwas, das in Benchmark-Tabellen selten auftaucht: Wie schnell kann das Team das Produkt entwickeln, ausliefern, dazulernen und verbessern?
Bei vielen modernen Desktop-Anwendungen ist Electron darin außergewöhnlich gut.
Die knappe Ressource ist Entwicklungszeit
Das idealisierte Unternehmen für native Desktop-Software hat ein hervorragendes macOS-Team, ein weiteres Team für die Windows-Anwendung und vielleicht noch eines für die Linux-Unterstützung. Jede Anwendung ist sorgfältig für ihre Plattform optimiert, und alle Entwickler kennen das Betriebssystem, auf dem sie arbeiten, bis ins Detail.
Die meisten Unternehmen haben diesen Luxus nicht.
An einem Desktop-Produkt arbeiten vielleicht fünf Entwickler. Vielleicht auch nur zwei. Dieselben Entwickler müssen Funktionen entwickeln, Fehler beheben, die Leistung verbessern, auf Kundenanfragen reagieren, die Infrastruktur pflegen, mit Änderungen am Betriebssystem umgehen und das Produkt voranbringen.
Native Entwicklung macht das schwieriger, weil macOS, Windows und Linux tatsächlich unterschiedliche Plattformen sind. Sie haben unterschiedliche UI-Frameworks, APIs, Berechtigungssysteme, Lebenszyklusabläufe, Installationsprogramme, Update-Mechanismen, Benachrichtigungssysteme, Fensterverwaltungen, Barrierefreiheits-APIs und über Jahre angesammelte plattformspezifische Eigenheiten.
Electron verändert diese Ausgangslage. Es kombiniert Chromium, Node.js und Desktop-APIs zu einem gemeinsamen Anwendungsmodell für macOS, Windows und Linux. Ein und derselbe TypeScript-Entwickler kann eine Funktion oft von der Benutzeroberfläche bis zur Anwendungslogik umsetzen und auf allen Desktop-Plattformen ausliefern. Nativer Code bleibt verfügbar, wenn er wirklich gebraucht wird, wird aber zur Ausnahme statt zum Fundament des Produkts. Electron selbst beschreibt dies als einen seiner zentralen Vorteile: eine JavaScript-Codebasis für alle drei großen Desktop-Plattformen.
Dieser Unterschied summiert sich über die Jahre. Wenn jede wesentliche Funktion separate Implementierungen für Mac und Windows erfordert, zahlt das Unternehmen diesen Plattformaufschlag immer wieder: bei jeder Funktion, jeder Neugestaltung, jedem Experiment, jeder Fehlerbehebung, jeder Verbesserung der Barrierefreiheit und jeder Leistungsoptimierung.
Mit Electron fällt ein großer Teil dieser Arbeit nur einmal an.
Electron optimiert auf schnelle Iteration
Produkte werden selten großartig, weil die erste Implementierung perfekt war. Sie werden durch Iteration großartig.
Ein Team liefert etwas aus. Kunden nutzen es. Das Team lernt daraus. Es verändert die Funktion. Mehr Menschen nutzen sie. Ein weiteres Problem wird sichtbar. Das Team verbessert sie erneut.
Je kürzer der Kreislauf zwischen Idee, Umsetzung, Feedback und Verbesserung ist, desto schneller wird ein Produkt besser.
Electron eignet sich ungewöhnlich gut dafür, diesen Kreislauf zu verkürzen, weil es auf Technologien aufbaut, die Softwareunternehmen ohnehin überall einsetzen: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js und npm.
Das bedeutet, dass Unternehmen weit mehr als nur Quellcode gemeinsam nutzen können. Sie können Entwickler, UI-Komponenten, Werkzeuge, Bibliotheken, Infrastruktur, Testansätze und unternehmensinternes Wissen zwischen ihren Web- und Desktop-Produkten teilen.
Ein Frontend-Entwickler ist nicht plötzlich außen vor, nur weil das Unternehmen Unterstützung beim Windows-Client braucht. Ein Desktop-Entwickler kann zur Webanwendung beitragen. Ein Full-Stack-TypeScript-Entwickler kann zwischen Produkten wechseln, wenn sich die Prioritäten ändern.
Für ein kleines oder mittelgroßes Unternehmen kann diese Flexibilität weit mehr wert sein als die Einsparung von 100 MB RAM.
Ein Blick darauf, wer Electron tatsächlich nutzt
Electron wird manchmal als Abkürzung für Unternehmen beschrieben, die nicht bereit sind, in eine „richtige“ Desktop-Anwendung zu investieren. Die damit entwickelten Produkte machen es zunehmend schwer, dieses Argument aufrechtzuerhalten.
Das Electron-Projekt selbst hebt Produkte wie Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom und Canva hervor. Das sind keine einfachen Hilfsprogramme. Viele zählen zu den anspruchsvollsten und meistgenutzten Produktivitätsanwendungen der Welt.
Visual Studio Code ist ein besonders aufschlussreiches Beispiel. Microsoft könnte seinen wichtigsten Code-Editor mit praktisch jeder beliebigen Windows-Technologie entwickeln. Dennoch nutzt VS Code Electron unter Windows, macOS und Linux. Es bietet Terminals, Debugging, Sprachserver, Git-Integration, Remote-Entwicklung, Notebooks, Erweiterungen und hochgradig angepasste Editoren.
Die interessante Frage ist nicht, ob Microsoft Arbeitsspeicher sparen könnte, indem es drei separate native Versionen entwickelt. Natürlich könnte es das.
Die bessere Frage ist, ob sich VS Code genauso schnell weiterentwickelt hätte, plattformübergreifend genauso konsistent geblieben wäre und ein derart großes Ökosystem aufgebaut hätte, wenn jede wichtige Fähigkeit mehrere separate Implementierungen erfordert hätte.
ChatGPT und Claude zeigen den Unterschied im Ansatz
Auch der Kontrast zwischen ChatGPT und Claude ist aufschlussreich.
OpenAI entwickelte zunächst eine eigene native macOS-Anwendung für ChatGPT. Anthropic hingegen entwickelte Claude Desktop auf Basis von Electron und verfügte damit von Anfang an über eine gemeinsame Desktop-Grundlage für verschiedene Plattformen.
Dieser Unterschied wurde wichtiger, als die Produkte ausgebaut wurden. Claude Desktop konnte Funktionen wie MCP-Integrationen, Erweiterungen und Claude Code innerhalb derselben plattformübergreifenden Anwendung ergänzen. Anthropic unterstützt Claude Code inzwischen direkt in seiner Desktop-Anwendung, einschließlich mehrerer lokaler und entfernter Sitzungen.
Auch OpenAI richtete seine neuere plattformübergreifende Desktop-Entwicklung später auf Electron aus, und Electron führt inzwischen sowohl ChatGPT als auch Claude unter den bekannten Electron-Anwendungen auf.
Es wäre übertrieben zu behaupten, dass Electron allein den Unterschied im Entwicklungstempo erklärt. Teamgröße, Prioritäten, Produktstrategie und interne Organisation spielen ebenfalls eine Rolle. Der architektonische Vorteil ist jedoch klar: Eine gemeinsame plattformübergreifende Grundlage erleichtert es, Funktionen auf verschiedenen Betriebssystemen auszuliefern, ohne separate Implementierungen pflegen zu müssen.
Genau diese Art von Vorteil wird umso wertvoller, je größer ein Desktop-Produkt wird.
Evernote lernte die Kosten separater Clients kennen
Evernote ist eines der deutlichsten historischen Beispiele für dieses Problem.
Jahrelang pflegte Evernote unterschiedliche Anwendungen für Mac, Windows, Mobilgeräte und das Web. Mit der Zeit sammelten sich in diesen Produkten unterschiedliche Verhaltensweisen, Unterschiede bei der Darstellung, historisch gewachsene Annahmen und Synchronisierungsprobleme an.
2020 entwickelte Evernote seine Windows- und Mac-Anwendungen auf Basis einer gemeinsamen Codebasis neu. Laut dem Unternehmen sollte die neue Grundlage die Apps stabiler machen, schnellere Fehlerbehebungen ermöglichen, häufigere Veröffentlichungen neuer Funktionen erlauben und die Synchronisierung zwischen den Plattformen verbessern.
Diese Migration verlief nicht schmerzfrei, und manche langjährigen Nutzer störten sich am anfänglichen Verlust plattformspezifischer Funktionen. Doch der Grund, weshalb Evernote eine so kostspielige Neuentwicklung auf sich nahm, ist interessanter als die Migrationsprobleme selbst.
Sobald ein Produkt einen umfangreichen Editor, Offline-Speicherung, Suche, Anhänge, Zusammenarbeit, Aufgaben, Kalender und komplexe Synchronisierung bietet, wird die Pflege mehrerer unabhängiger Implementierungen immer teurer. Fehler verhalten sich unterschiedlich. Die Darstellung unterscheidet sich. Die Synchronisierungslogik interagiert mit unterschiedlichen lokalen Architekturen. Jede wesentliche Produktänderung muss in mehreren Clients umgesetzt werden.
Eine gemeinsame Architektur lässt schwierige Probleme nicht verschwinden. Sie ermöglicht dem Unternehmen, mehr davon nur einmal lösen zu müssen.
Linux ist vielleicht der am meisten unterschätzte Vorteil von Electron
Linux macht die Argumente für Electron noch überzeugender.
Linux angemessen zu unterstützen, ist schwierig. Anders als macOS oder Windows ist der „Linux-Desktop“ keine einzelne, streng kontrollierte Plattform. Entwickler müssen mit unterschiedlichen Distributionen, Paketformaten, Desktop-Umgebungen, Grafik-Stacks, Systembibliotheken und Anzeigeprotokollen umgehen.
Für viele Softwareunternehmen wäre die wirtschaftlich vernünftige Entscheidung schlicht, Linux nicht zu unterstützen.
Electron verändert diese wirtschaftliche Rechnung.
Weil Electron eine gemeinsame Laufzeitumgebung für macOS, Windows und Linux bereitstellt, kann es erheblich einfacher sein, Linux-Unterstützung hinzuzufügen, als eine separate native Linux-Implementierung zu pflegen. Das ist einer der Gründe, weshalb Linux-Nutzer heute Zugang zu vielen wichtigen Desktop-Anwendungen haben, die früher möglicherweise nie einen offiziellen Linux-Client erhalten hätten.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian und viele andere Werkzeuge können Linux unterstützen, ohne eine völlig separate GTK- oder Qt-Anwendung pflegen zu müssen.
Electron nimmt Anwendungsentwicklern außerdem einen großen Teil der Linux-spezifischen Komplexität ab. Ein gutes Beispiel ist der Wechsel von X11 zu Wayland. Die Verantwortlichen für Electron haben beschrieben, wie der Wayland-Übergang von Chromium die Electron-Anwendungen praktisch mitgenommen hat. Dadurch musste jedes Anwendungsteam weniger Arbeit am Anzeige-Stack selbst erledigen.
Ohne Frameworks wie Electron würden viele Unternehmen keine nativen Linux-Clients entwickeln. Sie würden einfach macOS und Windows unterstützen und Linux-Nutzern nur einen Browser-Tab lassen.
Electron hat wahrscheinlich mehr für kommerzielle Linux-Desktop-Software getan, als ihm zugutegehalten wird.
Selbst Microsoft entscheidet sich zunehmend für Webtechnologien
Microsoft ist vielleicht das stärkste Gegenbeispiel zur Vorstellung, dass ernstzunehmende Windows-Software immer native Windows-UI-Frameworks nutzen sollte.
Microsoft kontrolliert Windows. Es kontrolliert Win32, .NET, WinUI, WebView2 und große Teile der Plattform, auf der Entwickler aufbauen. Wenn vollständig native Windows-Entwicklung immer die offensichtlich richtige Antwort wäre, hätte Microsoft die bestmöglichen Voraussetzungen, sie überall einzusetzen.
Das tut es nicht.
Visual Studio Code nutzt Electron. Teams basiert weiterhin auf React, TypeScript und Chromium, selbst nachdem Microsoft Electron durch einen stärker optimierten WebView2-Host ersetzt hat. Auch das neue Outlook für Windows stützt sich stark auf Webtechnologien, und Microsoft beschreibt diese Architektur ausdrücklich als Möglichkeit, die Agilität zu verbessern, Funktionen schneller auszuliefern und ein konsistenteres Nutzungserlebnis zu schaffen.
Teams ist besonders aufschlussreich. Microsoft wollte die Leistung verbessern und den Ressourcenverbrauch senken und änderte deshalb die Architektur. Doch es schrieb die Benutzeroberfläche nicht als traditionelle native Windows-Anwendung neu.
Es behielt den Web-Stack bei und optimierte die Architektur darum herum.
Dieser Unterschied ist wichtig. Microsoft entschied, dass die organisatorischen Vorteile von React, TypeScript und Chromium erhaltenswert waren, auch während es die Leistung mit Nachdruck verbesserte.
Darin steckt noch eine weitere Erkenntnis. Microsoft selbst hat im Laufe der Jahre viele Generationen von Technologien für Windows-Anwendungen eingeführt: Win32, WPF, UWP, WinUI und andere. Ein Unternehmen, das sich für „natives Windows“ entscheidet, wählt nicht unbedingt eine zeitlose Plattform. Oft setzt es auf eine bestimmte Generation des von Microsoft bevorzugten Frameworks.
Die Webplattform ist, durchaus ironischerweise, zu einer der stabileren verfügbaren Zielplattformen für Anwendungen geworden.
Personalgewinnung ist Teil der Architektur
Die Wahl eines Frameworks bestimmt auch, wen man einstellen kann.
JavaScript- und TypeScript-Entwickler bilden einen der größten Fachkräftepools der Branche. Ein Unternehmen, das mit Electron entwickelt, kann aus diesem Pool rekrutieren, statt separate Teams aus erfahrenen macOS-, Windows- und Linux-Spezialisten zu benötigen.
Native Spezialisten bleiben wertvoll. Anspruchsvolle Desktop-Produkte brauchen weiterhin Entwickler, die Betriebssysteme tiefgehend verstehen. Doch Electron verändert, wie viele Spezialisten man benötigt.
Statt den Großteil der Anwendung von Plattformexperten entwickeln lassen zu müssen, kann man einen relativ kleinen Anteil nativen Integrationscodes pflegen und den Großteil des Teams am gemeinsamen Produkt arbeiten lassen.
Das ist noch wichtiger, wenn ein Unternehmen bereits eine Webanwendung hat. React-Komponenten lassen sich manchmal gemeinsam nutzen. TypeScript-Bibliotheken können wiederverwendet werden. Produktlogik kann zwischen Web und Desktop übertragen werden. Entwickler können das Team wechseln, ohne ein völlig anderes Ökosystem erlernen zu müssen.
Auch die Personalgewinnung wird weniger anfällig. Wenn der einzige Entwickler, der Ihren nativen Windows-Client wirklich tiefgehend versteht, das Unternehmen verlässt, kann es schwierig sein, dieses Fachwissen zu ersetzen. Mit Electron nutzt ein viel größerer Teil der Codebasis Technologien, mit denen der Rest der Organisation vertraut ist.
Ein Framework bestimmt deshalb nicht nur, wie eine Benutzeroberfläche dargestellt wird. Es beeinflusst auch, wie die Entwicklungsorganisation selbst strukturiert werden kann.
Nativ bedeutet nicht automatisch bessere Software
Entwickler verwenden „nativ“ oft fast als Synonym für „schnell“.
Das ist es nicht.
Native APIs geben Entwicklern die Möglichkeit, eine sehr effiziente Anwendung zu erstellen. Ob das fertige Produkt dies tatsächlich erreicht, hängt von der Architektur, dem Team, dem Budget und dem Umfang der Optimierungsarbeit ab, den sich das Unternehmen leisten kann.
Eine native Anwendung kann trotzdem langsam, fehlerhaft, speicherhungrig, inkonsistent oder schlecht gepflegt sein.
Noch wichtiger ist: Wenn ein begrenztes Team auf mehrere native Implementierungen aufgeteilt wird, erhält jede Implementierung weniger Entwicklungsstunden.
Stellen Sie sich vor, ein Unternehmen hat sechs Entwickler für sein Desktop-Produkt zur Verfügung. Eine Möglichkeit ist, sie zwischen Mac und Windows aufzuteilen und Linux vielleicht nicht zu unterstützen. Eine andere ist, fast alle sechs Entwickler an einer gemeinsamen Electron-Anwendung arbeiten zu lassen, die alle drei Plattformen bedient.
Welcher Ansatz gibt dem Unternehmen mehr Entwicklungskapazität, um die Startzeit zu verbessern, Speicherlecks zu beheben, Interaktionen zu verfeinern, die Barrierefreiheit zu verbessern, Abstürze zu reduzieren und auf Nutzer zu reagieren?
Es ist keineswegs offensichtlich, dass die nativen Anwendungen das bessere Produkt hervorbringen.
Daraus ergibt sich ein interessantes Paradox: Ein Framework, das etwas mehr Rechnerressourcen verbraucht, kann es einem Unternehmen ermöglichen, ein besser optimiertes Produkt zu entwickeln, weil es weitaus weniger Entwicklungsressourcen beansprucht.
Electron bietet eine kontrollierte Plattform
Electron hat außerdem einen weiteren Vorteil, der leicht übersehen wird: Es liefert die Chromium-Laufzeitumgebung mit, für die die Anwendung entwickelt und mit der sie getestet wurde.
Dadurch entfällt eine wichtige Variable in der plattformübergreifenden Entwicklung.
Frameworks, die auf Webviews des Betriebssystems basieren, können kleinere Anwendungen hervorbringen. Der Kompromiss besteht jedoch darin, dass dasselbe Frontend unter Windows möglicherweise auf WebView2, unter macOS auf WKWebView und unter Linux auf WebKitGTK läuft. Diese Engines haben unterschiedliche Fähigkeiten, Fehler, Veröffentlichungszyklen und Darstellungsverhalten.
Electron geht einen anderen Kompromiss ein: Es bündelt die Laufzeitumgebung und macht sie zum Bestandteil der Anwendung.
Ja, das kostet Speicherplatz.
Aber es gibt Entwicklern eine deutlich konsistentere Zielumgebung über drei sehr unterschiedliche Betriebssysteme hinweg.
Konsistenz hat einen enormen Wert für die Entwicklung.
Wenn Electron nicht ausreicht, ist nativer Code weiterhin möglich
Die Entscheidung für Electron bedeutet nicht, auf den Zugriff auf native Fähigkeiten zu verzichten.
Electron-Anwendungen können bei Bedarf native Module und plattformspezifischen Code verwenden. Das bedeutet, die architektonische Entscheidung lautet nicht wirklich:
100 % nativ oder 100 % JavaScript.
Für viele Produkte ist ein besseres Modell:
Der Großteil der Anwendung ist gemeinsam nutzbar, mit einem kleinen Anteil nativen Codes dort, wo das Betriebssystem ihn tatsächlich erfordert.
Nativer Code wird zu einer Ausweichmöglichkeit statt zum Fundament des gesamten Produkts.
Für viele Unternehmen ist das eine wesentlich bessere Verteilung des Entwicklungsaufwands.
Nutzer interessieren sich für Produkte, nicht für Frameworks
Es gibt eine kleine Gruppe technisch versierter Nutzer, die die Aktivitätsanzeige öffnen, mehrere Chromium-Prozesse bemerken und sich sofort darüber beschweren, dass eine Anwendung Electron nutzt.
Die meisten Nutzer tun das nicht.
Ihnen ist egal, dass Slack Electron nutzt. Ihnen ist egal, dass VS Code mit Webtechnologien entwickelt wurde. Sie wissen nicht, welches Framework Claude verwendet. Ihnen ist wichtig, ob die Software ihnen hilft, ihre Arbeit zu erledigen.
Wenn eine Anwendung schnell genug startet, sich reaktionsschnell anfühlt, selten abstürzt und das Problem des Nutzers löst, bleibt die verwendete Technologie weitgehend unsichtbar.
Umgekehrt gilt dasselbe. Eine native Anwendung wird nicht automatisch zu einem guten Produkt, weil sie Swift oder WinUI nutzt.
Software konkurriert auf Produktebene, nicht auf Framework-Ebene.
Optimieren Sie das Unternehmen, nicht nur die Binärdatei
Electron verursacht reale Kosten. Es benötigt mehr Speicherplatz. Sein Grundbedarf an Arbeitsspeicher ist in der Regel höher als der einer kleinen nativen Anwendung. Es gibt durchaus Produkte, bei denen diese Kosten Electron zur falschen Wahl machen.
Ein winziges Menüleisten-Tool braucht wahrscheinlich kein Chromium. Ein Gerätetreiber ganz sicher nicht. Spiele, professionelle Audiosoftware und extrem latenzempfindliche Anwendungen haben andere Anforderungen. Und wenn Ihr Produkt immer nur auf einem einzigen Betriebssystem laufen wird, lässt sich native Entwicklung viel leichter rechtfertigen.
Doch ein sehr großer Anteil moderner Desktop-Software fällt nicht in diese Kategorien.
Er besteht aus komplexen Benutzeroberflächen, die mit Cloud-Diensten verbunden sind. Er muss unter Windows und macOS laufen, und zunehmend erwarten Nutzer auch Linux-Unterstützung. Er muss sich kontinuierlich weiterentwickeln. Er konkurriert mit Produkten, die jede Woche Änderungen ausliefern. Und er wird gewöhnlich von einem Unternehmen mit einer begrenzten Zahl von Entwicklern gebaut.
Bei diesen Produkten ist Entwicklerproduktivität ein Teil der Anwendungsleistung.
Electron ermöglicht es einem Unternehmen, aus einem deutlich größeren Fachkräftepool zu rekrutieren, Entwickler zwischen Web und Desktop einzusetzen, eine zentrale Anwendung statt mehrerer zu pflegen, das JavaScript-Ökosystem wiederzuverwenden, Funktionen konsistenter über Betriebssysteme hinweg auszuliefern, Linux zu Kosten zu unterstützen, die andernfalls oft schwer zu rechtfertigen wären, und mehr Entwicklungszeit in die Verbesserung des Produkts statt in die Pflege paralleler Implementierungen zu investieren.
Die Kosten von Electron lassen sich leicht in Megabyte messen.
Die Kosten der Alternative sind schwerer zu erkennen. Sie zeigen sich in zusätzlichen Entwicklern, doppelten Implementierungen, längeren Veröffentlichungszyklen, plattformspezifischen Fehlern, Schwierigkeiten bei der Personalgewinnung, organisatorischen Silos, nicht unterstützten Linux-Nutzern und Funktionen, die alle Nutzer erst Monate später erreichen.
Diese Kosten erscheinen nicht in der Aktivitätsanzeige.
Doch für das Unternehmen, das die Software entwickelt, können sie erheblich größer sein.
Das Ziel der Softwareentwicklung ist nicht, die kleinste Binärdatei zu erzeugen.
Es ist, das beste Produkt zu entwickeln, das Ihre Organisation ausliefern, pflegen und kontinuierlich verbessern kann.
Für eine überraschend große Klasse von Desktop-Anwendungen bleibt Electron eine der effizientesten Möglichkeiten, genau das zu tun.