Der Schock über die App-Größe verdeckt einen größeren Zielkonflikt
Electron, ein Framework, das wegen seines Ressourcenbedarfs oft verspottet wird, bleibt die bevorzugte Wahl für Desktop-KI-Anwendungen von Branchengrößen wie Anthropic, OpenAI und Moonshot AI AI. Dieses scheinbare Paradox – warum für modernste KI eine speicherhungrige, sperrige Lösung wählen? – offenbart einen grundlegenden Zielkonflikt.
Man betrachte den deutlichen Größenunterschied: OpenAIs ursprüngliche native Mac-App ChatGPT war mit 159 MB schlank. Ihr auf Electron basierender Nachfolger, die Codex-App, wächst auf etwa 1,7 GB an, wobei ein Großteil dieses Umfangs auf gebündelte Entwicklerwerkzeuge zurückgeht. Selbst eine leere Electron-Basisanwendung kommt noch auf 268 MB.
Solche Zahlen laden zur Kritik ein, verschleiern aber die eigentliche Entscheidung der KI-Unternehmen. Es geht nicht allein um die Download-Größe, sondern um die enormen Kosten, eine wirklich zuverlässige Anwendung über unterschiedliche Betriebssysteme hinweg zu entwickeln, zu testen und zu pflegen.
Alternativen wie Tauri und Wails bieten durch die Nutzung systemeigener Web-Engines einen geringeren Platzbedarf, führen aber Inkonsistenzen ein. Eine App, die in der Safari-Engine von macOS einwandfrei dargestellt wird, kann unter WebKitGTK von Linux oder der Edge-Engine von Windows fehlerhaft sein – ein Albtraum für die Qualitätssicherung.
Indem Electron seine eigene Chromium-Laufzeit bündelt, sorgt es unabhängig vom zugrunde liegenden Betriebssystem für eine einheitliche Nutzererfahrung. Diese Konsistenz verringert trotz der größeren Binärdatei die Reibungsverluste in der Entwicklung erheblich und beschleunigt die Bereitstellung – ein entscheidender Vorteil für KI-Firmen, die schnell iterieren.
Native Apps bringen Feinschliff – und vervielfachen die Arbeit
Die native Entwicklung setzt dagegen auf das jeweilige Toolkit jeder Plattform – etwa SwiftUI für den Mac –, um Anwendungen zu liefern, die sich tief in das Betriebssystem integrieren. Dieser Ansatz verspricht Spitzenleistung und eine nahtlose Nutzererfahrung, die sich an plattformspezifisches Verhalten und Designkonzepte anpasst.
Diese Detailtreue hat jedoch einen hohen organisatorischen Preis. Der Betrieb getrennter nativer Anwendungen erfordert eigene, parallel arbeitende Teams und führt oft zu doppelter Arbeit an der Oberfläche auf mehreren Plattformen. Vor dem Wechsel zu Electron unterhielt 1Password Berichten zufolge vier getrennte Teams für Desktop-Plattformen – ein enormer Ressourcenaufwand für jedes Softwareunternehmen, erst recht für ein schnell wachsendes.
Native Entwicklung ist nicht per se eine schlechte Wahl, sie bremst jedoch Produkte erheblich, die sich ständig verändern. Wenn Funktionen, UI-Elemente oder Kernfunktionalitäten wöchentlich überarbeitet werden, bindet der Abgleich mehrerer nativer Implementierungen über Plattformen hinweg enorme Entwicklungszeit und verlangsamt die Release-Zyklen. Für KI-Unternehmen wie Anthropic, OpenAI und Moonshot AI AI, bei denen schnelles Experimentieren und Ausliefern entscheidend sind, ist dieser Mehraufwand schlicht untragbar. Sie priorisieren eine schnelle Auslieferung gegenüber dem Einsparen von Megabytes.
Die leichtere Alternative hat einen Haken bei der Browser-Engine
Leichtere Alternativen wie Tauri (Rust) und Wails (Go) versprechen Entlastung von Electrons Schwergewicht. Diese Frameworks nutzen die bereits vorhandene Webview des Betriebssystems für das Rendering, während Rust oder Go die Interaktionen auf Systemebene übernimmt. Das Ergebnis ist ein deutlich geringerer Platzbedarf: Eine leere Tauri-App wiegt beispielsweise etwa 5 MB, ein starker Kontrast zu Electrons typischer Basisgröße von 268 MB.
Der Haken ist die Konsistenz. Tauri und Wails verlassen sich auf die Web-Engine, die das Betriebssystem bereitstellt: WebKit unter macOS, WebKitGTK unter Linux und Microsoft Edges WebView2 unter Windows. Diese Fragmentierung bedeutet, dass eine App auf einer Plattform einwandfrei dargestellt wird, auf einer anderen jedoch Darstellungsfehler zeigt. Entwickler können solche Probleme nicht immer mit einem App-Update beheben, da die Engine zum Betriebssystem selbst gehört.
Diese systembedingte Uneinheitlichkeit erzwingt eine schwierige Entscheidung. Um eine einheitliche Nutzererfahrung auf allen Plattformen zu gewährleisten, beginnen selbst diese schlanken Alternativen, eigene Browser-Engines zu bündeln. Electrobun bietet bereits eine Option mit gebündeltem Chromium, und auch die Alpha-Version von Tauri 3 führt eine solche ein. Diese Rückkehr zu einer gebündelten Engine stellt die Konsistenz wieder her, bringt aber zwangsläufig auch einen Teil des Größen-Kompromisses zurück, der Electron so umstritten gemacht hat – ein Beleg dafür, wie schwierig es ist, alles zugleich zu haben. Mehr zur ursprünglichen Begründung finden Sie unter Why Electron | Electron Documentation.
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
Warum Konsistenz im Rennen um KI-Apps gewinnt
Electrons gebündeltes Chromium und die Node.js-Laufzeit, oft als größte Sünde genannt, sind genau sein stärkstes Merkmal. Teams erhalten die vollständige Kontrolle über die Rendering-Umgebung und sichern so eine einheitliche Oberfläche unter macOS, Windows und Linux. Diese Konsistenz ist nicht nur eine Frage der Optik, sondern ein strategischer Vorteil.
Für sich rasch entwickelnde KI-Produkte, bei denen sich Funktionen und Arbeitsabläufe ständig verändern, wird eine gemeinsame Codebasis unverzichtbar. Anthropic, OpenAI und Moonshot AI AI können Desktop-Erlebnisse ausliefern und verfeinern, ohne den enormen Koordinationsaufwand mehrerer nativer Implementierungen. Man stelle sich den Aufwand vor, wenn OpenAI für jedes ChatGPT-Update separate SwiftUI-, WinUI- und GTK-Teams koordinieren müsste.
Letztlich hängt die Entscheidung von den Prioritäten ab. Electron eignet sich für Teams, die Parität und Iterationsgeschwindigkeit über alles stellen und dafür den großen Platzbedarf zugunsten eines vorhersagbaren plattformübergreifenden Verhaltens in Kauf nehmen. Tauri oder Wails sind mit ihrer geringeren Anfangsgröße (eine leere Tauri-App mit 5 MB auf dem Mac) überzeugend für Anwendungen, bei denen die Größe der Binärdatei entscheidend ist und die Eigenheiten der System-Webviews beherrschbar sind.
Native Entwicklung bleibt der Goldstandard für plattformspezifischen Feinschliff, jedoch nur dann, wenn die besondere Nutzererfahrung den exponentiellen Anstieg von Entwicklungskosten und -zeit rechtfertigt. Wie die anhaltende Dominanz von Electron bei führenden KI-Unternehmen zeigt, wiegt für viele eine vorhersagbare plattformübergreifende Auslieferung den Leistungsverlust auf.
Häufig gestellte Fragen
Warum setzen KI-Unternehmen auf Electron?
Mit Electron können Teams Desktop-Apps für mehrere Betriebssysteme aus einer einzigen Codebasis entwickeln und dabei die Benutzeroberfläche einheitlich halten.
Warum gilt Electron als schwergewichtig?
Electron bündelt Chromium und Node.js mit einer App, was deren Download-Größe und möglicherweise auch den Speicherverbrauch erhöht.
Wie unterscheidet sich Tauri von Electron?
Tauri verwendet in der Regel die in das jeweilige Betriebssystem integrierte Webview, statt Chromium zu bündeln. Dadurch können Apps kleiner, aber auf den verschiedenen Plattformen weniger einheitlich sein.
Ist eine native Desktop-App immer besser?
Nicht unbedingt. Native Apps können sich besser ins System einfügen und kompakt bleiben, doch die Unterstützung mehrerer Plattformen kann deutlich mehr Entwicklungsaufwand erfordern.