Electron und Tauri sind zwei beliebte Frameworks zur Entwicklung von Desktop-Anwendungen mit Webtechnologien. Beide ermöglichen es Entwicklern, mit HTML, CSS, JavaScript und modernen Frontend-Frameworks Anwendungen für macOS, Windows und Linux zu erstellen. Sie verfolgen jedoch grundlegend unterschiedliche Ansätze bei der Ausführung dieser Anwendungen.
Electron liefert Chromium und Node.js mit jeder Anwendung aus und bietet damit eine einheitliche Browser-Engine und Laufzeitumgebung über alle Betriebssysteme hinweg. Tauri verfolgt einen schlankeren Ansatz und nutzt die vorhandene Webview des Betriebssystems zusammen mit einem Rust-basierten Backend. Dieser architektonische Unterschied wirkt sich auf Anwendungsgröße, Speichernutzung, Leistung, Sicherheit, Kompatibilität und Entwicklerproduktivität aus.
Tauri wird häufig als modernere, leichtgewichtige Alternative zu Electron präsentiert. Obwohl es echte Vorteile bietet, insbesondere bei Anwendungsgröße und Ressourcenverbrauch, bleibt Electron für viele Arten von Desktop-Software eine überzeugende Wahl. Bekannte Anwendungen wie Visual Studio Code, Slack, Discord, Notion und Figma nutzen Electron. Auch bei WebCatalog haben wir uns für Electron als Grundlage unserer plattformübergreifenden Desktop-Anwendungen entschieden.
Welches Framework sollten Sie also wählen? Die jeweiligen Vor- und Nachteile zu verstehen, ist hilfreicher, als eines der beiden Frameworks zum Sieger zu erklären.
Electron vs. Tauri auf einen Blick
Bevor wir die technischen Unterschiede genauer betrachten, zeigt die folgende Übersicht, wie sich die beiden Frameworks bei wichtigen Merkmalen unterscheiden.
| Merkmal | Electron | Tauri |
|---|---|---|
| Browser-Engine | Mitgeliefertes Chromium | System-Webview |
| Backend | Node.js | Rust |
| Anwendungsgröße | In der Regel größer | In der Regel kleiner |
| Grundlegender Arbeitsspeicherbedarf | In der Regel höher | In der Regel niedriger |
| Plattformübergreifende Einheitlichkeit | Hoch | Je nach Plattform unterschiedlich |
| JavaScript-Ökosystem | Umfassende Node.js-Unterstützung | JavaScript im Frontend, native APIs über Plugins und Befehle |
| Sicherheitsmodell | Chromium-Sandboxing, Kontextisolierung, IPC | Rust-Backend, Berechtigungen auf Basis von Capabilities, IPC |
| Desktop-Plattformen | macOS, Windows, Linux | macOS, Windows, Linux |
| Unterstützung für Mobilgeräte | Keine offizielle Unterstützung | Android und iOS |
| Am besten geeignet für | Komplexe, Chromium-abhängige Desktop-Apps | Leichtgewichtige Apps und eng mit dem Betriebssystem integrierte Hilfsprogramme |
Diese Unterschiede gehen hauptsächlich auf eine Architekturentscheidung zurück: Wird eine Browser-Engine mitgeliefert oder die vom Betriebssystem bereitgestellte verwendet?
Architektur: Mitgeliefertes Chromium vs. System-Webviews
Der größte Unterschied zwischen Electron und Tauri liegt darin, wie sie Webinhalte darstellen. Electron enthält eine eigene Chromium-Engine. Das bedeutet, dass Anwendungen unter macOS, Windows und Linux im Wesentlichen dieselbe Browsertechnologie verwenden. Entwickler können sich auf eine bestimmte Chromium-Version und die von ihr unterstützten Web-APIs verlassen, unabhängig davon, welches Betriebssystem ihre Nutzer installiert haben.
Tauri verwendet stattdessen die Webview, die das jeweilige Betriebssystem bereitstellt. Dadurch muss deutlich weniger Software mit einer Anwendung ausgeliefert werden. Allerdings bedeutet dies auch, dass dieselbe Anwendung je nach Plattform mit unterschiedlichen Browser-Engines ausgeführt werden kann.
| Plattform | Electron | Tauri |
|---|---|---|
| macOS | Chromium | WKWebView (WebKit) |
| Windows | Chromium | WebView2 (Chromium) |
| Linux | Chromium | WebKitGTK |
| Android | Nicht offiziell unterstützt | Android WebView |
| iOS | Nicht offiziell unterstützt | WKWebView |
Bei Anwendungen mit einfachen Benutzeroberflächen haben diese Unterschiede in der Praxis möglicherweise kaum Auswirkungen. Die meisten modernen Frontend-Frameworks funktionieren sowohl mit Chromium als auch mit WebKit gut. Bei Anwendungen, die auf bestimmte Browser-APIs, komplexes Rendering-Verhalten oder fortgeschrittene Webfunktionen angewiesen sind, können jedoch Kompatibilitätsprobleme auftreten.
Mit Electron können Entwickler gegen eine bekannte Chromium-Version testen und genau diese Version an die Nutzer ausliefern. Mit Tauri müssen sie Unterschiede zwischen Browser-Engines und möglicherweise auch zwischen verschiedenen Versionen der System-Webviews berücksichtigen. Das ist besonders wichtig bei der Fehlersuche, wenn Probleme nur unter bestimmten Betriebssystemen oder Linux-Distributionen auftreten.
Keiner der beiden Ansätze ist grundsätzlich überlegen. Tauri reduziert Doppelungen, indem es bereits auf dem Computer installierte Software nutzt. Electron nimmt dagegen eine größere Anwendung in Kauf, um mehr Kontrolle und Einheitlichkeit zu bieten.
Anwendungsgröße, Speichernutzung und Leistung
Einer der deutlichsten Vorteile von Tauri ist die Anwendungsgröße. Da Electron Chromium und Node.js mitliefert, können selbst relativ einfache Electron-Anwendungen Hunderte Megabyte Speicherplatz belegen. Tauri-Anwendungen können erheblich kleiner sein, weil sie die System-Webview nutzen, statt eine vollständige Browser-Engine in das Anwendungspaket aufzunehmen.
Tauri kann außerdem einen geringeren grundlegenden Arbeitsspeicherbedarf haben, insbesondere bei leichtgewichtigen Anwendungen mit wenig Hintergrundverarbeitung. Sein Rust-Backend ist effizient, und es muss keine separate, mitgelieferte Browser-Laufzeitumgebung betreiben. Bei kleinen Hilfsprogrammen, Notiz-Tools und Anwendungen mit relativ einfachen Benutzeroberflächen können diese Vorteile erheblich sein.
Kleinere Anwendungen sind jedoch nicht zwangsläufig schneller. Sowohl Electron als auch Tauri verwenden letztlich Browser-Engines zur Darstellung ihrer Benutzeroberflächen, und die Frontend-Leistung hängt weiterhin stark vom Anwendungscode ab. Eine ineffiziente React-Komponente, eine aufwendige JavaScript-Operation oder ein Speicherleck bleibt unabhängig vom Framework ein Problem.
Außerdem gibt es einen wichtigen Unterschied zwischen Anwendungsgröße und gesamtem Ressourcenverbrauch. Tauri verzichtet nicht auf die Browser-Engine, sondern verwendet lediglich eine vom Betriebssystem bereitgestellte. Unter Windows bedeutet das, sich auf WebView2 zu stützen, das auf modernen Windows-Installationen in der Regel verfügbar ist. Unter macOS und Linux werden die jeweiligen WebKit-Implementierungen genutzt.
Für einen aussagekräftigen Leistungsvergleich sollten Entwickler Folgendes messen:
- Anwendungsgröße: Downloadgröße und belegter Speicherplatz nach der Installation.
- Startzeit: Wie schnell die Anwendung bedienbar wird.
- Arbeitsspeicherbedarf im Leerlauf: Speicherverbrauch, wenn die Anwendung geöffnet, aber inaktiv ist.
- Arbeitsspeicher- und CPU-Auslastung bei aktiver Nutzung: Ressourcenverbrauch bei realistischen Arbeitslasten.
- Reaktionsfähigkeit: Rendering-Leistung und Latenz bei Benutzerinteraktionen.
Die Ergebnisse hängen von der jeweiligen Anwendung ab. Tauri hat bei leichtgewichtigen Anwendungen oft einen Vorteil, während die einheitliche Chromium-Umgebung von Electron das plattformübergreifende Testen und Optimieren komplexer Anwendungen erleichtern kann.
Entwicklererfahrung und Sicherheit
Electron bietet einen erheblichen Vorteil für Teams, die bereits Erfahrung mit JavaScript und TypeScript haben. Die Integration mit Node.js eröffnet den Zugang zu einem ausgereiften Ökosystem von Bibliotheken für Dateisystemoperationen, Netzwerkkommunikation, Datenbanken, Hintergrundprozesse und Betriebssystemfunktionen. Entwickler können anspruchsvolle Desktop-Anwendungen erstellen, ohne zwangsläufig eine weitere Programmiersprache in ihren Technologie-Stack aufnehmen zu müssen.
Tauri verwendet Rust für sein natives Backend und bietet dadurch hervorragende Leistung, Speichersicherheit und starke Garantien zur Kompilierzeit. Entwickler können ihre Benutzeroberflächen weiterhin mit React, Vue, Svelte oder anderen JavaScript-Frameworks erstellen. Für viele gängige native Operationen stellt Tauri Plugins und JavaScript-APIs bereit.
Die Implementierung von Funktionen außerhalb dieser APIs kann jedoch Rust- oder plattformspezifischen Code erfordern. Für Teams, die bereits mit Rust vertraut sind, kann dies ein Vorteil sein. Für Teams, die hauptsächlich mit TypeScript arbeiten, kann es zusätzliche Komplexität bedeuten.
Auch bei der Sicherheit verfolgen die beiden Frameworks unterschiedliche Ansätze. Tauri bietet ein auf Capabilities basierendes Berechtigungssystem, das einschränken soll, auf welche nativen Operationen Frontend-Code zugreifen kann. Electron bietet Chromium-Sandboxing, Kontextisolierung und Kontrollmöglichkeiten zur Beschränkung des Zugriffs auf Node.js und andere privilegierte APIs.
Beide Frameworks können bei korrekter Konfiguration sichere Anwendungen ermöglichen. Ebenso können beide Nutzer Sicherheitslücken aussetzen, wenn Entwickler zu weitreichende Berechtigungen vergeben oder unsicher mit nicht vertrauenswürdigen Inhalten umgehen.
Ein wichtiger Unterschied betrifft Sicherheitsupdates. Electron-Entwickler sind dafür verantwortlich, ihre mitgelieferte Chromium-Laufzeitumgebung zu aktualisieren und neue Anwendungsversionen bereitzustellen, sobald Sicherheitskorrekturen verfügbar sind. Tauri verlässt sich bei Sicherheitsupdates für die Browser-Engine in der Regel auf Aktualisierungen des Betriebssystems oder des Webview-Anbieters. Das nimmt Anwendungsentwicklern einen Teil der Wartungsaufgaben ab, wobei die Verfügbarkeit von Updates vom Betriebssystem des Nutzers und der installierten Webview abhängt.
Letztlich hängt Sicherheit stärker davon ab, wie eine Anwendung entwickelt und gewartet wird, als davon, welches Framework sie verwendet. Die Wahl von Tauri macht eine Anwendung nicht automatisch sicher, genauso wenig wie die Wahl von Electron sie automatisch unsicher macht.
Warum große Unternehmen weiterhin Electron verwenden
Trotz häufiger Kritik an Anwendungsgröße und Ressourcenverbrauch bleibt Electron eine beliebte Wahl für bedeutende Softwareprodukte. Einige der meistgenutzten Desktop-Anwendungen werden mit Electron entwickelt und zeigen damit, dass seine Architektur komplexe Software für Millionen von Menschen unterstützen kann.
Beispiele sind:
| Unternehmen | Anwendung |
|---|---|
| Microsoft | Visual Studio Code |
| Salesforce | Slack |
| Discord | Discord |
| Notion | Notion |
| Figma | Figma |
| Signal | Signal Desktop |
| GitHub | GitHub Desktop |
| OpenAI | ChatGPT Desktop |
Diese Anwendungen erfüllen sehr unterschiedliche Zwecke, von Softwareentwicklung und Kommunikation bis hin zu Design und Produktivität. Gemeinsam ist ihnen die Anforderung, anspruchsvolle Desktop-Anwendungen bereitzustellen und dabei die Vorteile von Webtechnologien zu nutzen.
Electron bietet ein ausgereiftes Ökosystem, eine einheitliche Chromium-Laufzeitumgebung und die Möglichkeit, Weboberflächen mit nativen Betriebssystemfunktionen zu kombinieren. Seine weite Verbreitung bedeutet außerdem, dass Entwickler von jahrelang gewachsener Dokumentation, Open-Source-Bibliotheken, Debugging-Tools und Lösungen für häufige Probleme profitieren können.
Bei großen Anwendungen können Entwicklungsproduktivität und Wartbarkeit wichtiger sein als eine möglichst kleine Installationsdatei. Zusätzliche hundert Megabyte Speicherplatz können ein vertretbarer Kompromiss sein, wenn dadurch die plattformübergreifende Entwicklung weniger komplex und die Anwendung leichter wartbar wird.
Das bedeutet weder, dass Electron immer die richtige Wahl ist, noch, dass jedes Unternehmen es aus denselben Gründen gewählt hat. Sein fortgesetzter Einsatz in großen produktiv genutzten Anwendungen zeigt jedoch, dass Electron weiterhin eine praktische, etablierte Option ist und keine veraltete Technologie, die Entwickler grundsätzlich ersetzen sollten.
Weitere Beispiele finden Sie in der offiziellen Electron-App-Galerie.
Warum wir bei WebCatalog Electron wählen
Bei WebCatalog verwenden wir Electron, um plattformübergreifende Desktop-Anwendungen zu entwickeln. Wir sind überzeugt, dass es für unsere spezifischen Anforderungen weiterhin das richtige Framework ist.
Mit WebCatalog können Nutzer Websites in Desktop-Anwendungen umwandeln, mit mehreren Konten unabhängig voneinander angemeldet bleiben und ihre Anwendungen unter macOS, Windows und Linux organisieren. Anders als bei einer herkömmlichen Desktop-Anwendung, bei der Entwickler das Frontend kontrollieren und für eine bestimmte Umgebung optimieren können, müssen wir eine große Vielfalt an Websites unterstützen, über die wir keine Kontrolle haben.
Diese Websites können unterschiedliche Authentifizierungssysteme, Speichermechanismen, Medienfunktionen, Browser-APIs und JavaScript-Frameworks verwenden. Eine Website, die in Chromium korrekt funktioniert, kann sich in WebKit anders verhalten. Die Kompatibilität mit mehreren Browser-Engines aufrechtzuerhalten, würde zusätzliche technische Herausforderungen mit sich bringen.
Die einheitliche Chromium-Laufzeitumgebung von Electron hilft uns, einen Großteil dieser Komplexität zu vermeiden. Sie ermöglicht es uns, auf allen unterstützten Desktop-Plattformen eine verlässlich einheitliche Browserumgebung bereitzustellen, statt auf unterschiedliche System-Webviews angewiesen zu sein.
Electron bietet außerdem ausgereifte APIs zur Verwaltung von Browser-Sitzungen, Cookies, Speicher, Berechtigungen und Navigation. Die Möglichkeiten zur Sitzungspartitionierung sind für WebCatalog besonders wertvoll, weil Nutzer damit mehrere unabhängige Anmeldesitzungen für dieselbe Website aufrechterhalten können.
Auch Tauri kann externe Websites anzeigen, und ähnliche Funktionen lassen sich mithilfe seiner Webview-APIs, Plugins oder plattformspezifischen Integrationen implementieren. Der Unterschied besteht darin, dass Electron eine einheitlichere Grundlage für Anwendungen bietet, bei denen Browserfunktionen im Mittelpunkt stehen, insbesondere wenn sie beliebige Dienste von Drittanbietern unterstützen müssen.
Die Linux-Unterstützung verstärkt diesen Vorteil. Linux-Distributionen unterscheiden sich erheblich hinsichtlich der verfügbaren Systembibliotheken, Desktop-Umgebungen und Softwareversionen. Die mitgelieferte Chromium-Laufzeitumgebung von Electron beseitigt eine wesentliche Ursache solcher Unterschiede. Tauri-Anwendungen müssen dagegen die auf jeder unterstützten Distribution verfügbare WebKitGTK-Umgebung berücksichtigen.
Diese Einheitlichkeit hat ihren Preis. Electron-Anwendungen sind größer, und Entwickler müssen den Ressourcenverbrauch sorgfältig steuern. Bei WebCatalog suchen wir kontinuierlich nach Möglichkeiten, diesen zusätzlichen Ressourcenbedarf zu verringern. Beispielsweise haben wir APFS-Klone eingeführt, um den Speicherplatzbedarf generierter Mac-Anwendungen zu reduzieren. Das zeigt, dass sich einige Nachteile von Electron beheben lassen, ohne das Framework aufzugeben.
Unsere Entscheidung beruht nicht auf der Überzeugung, dass Electron grundsätzlich besser als Tauri ist. Sie basiert auf den Anforderungen unseres Produkts. Für WebCatalog sind Browserkompatibilität, einheitliches Verhalten über Betriebssysteme hinweg und ausgereifte Funktionen zur Sitzungsverwaltung wertvoller als eine möglichst geringe Anwendungsgröße.
Wo Tauri im Vorteil ist
Obwohl wir bei WebCatalog Electron bevorzugen, gibt es viele Situationen, in denen Tauri die bessere Wahl sein kann. Für leichtgewichtige Desktop-Hilfsprogramme sind kleinere Anwendungspakete und ein geringerer grundlegender Ressourcenverbrauch überzeugende Vorteile. Anwendungen, die hauptsächlich ihr eigenes Frontend anzeigen, relativ einfache Anforderungen an native Funktionen haben und nicht von einer bestimmten Browser-Engine abhängen, können erheblich von der Architektur von Tauri profitieren.
Tauri ist auch für Entwickler attraktiv, die Rust bevorzugen oder native Anwendungslogik plattformübergreifend gemeinsam nutzen möchten. Seit Tauri 2 unterstützt das Framework neben Desktop-Betriebssystemen offiziell auch Android und iOS. Electron ist dagegen primär für die Desktop-Entwicklung konzipiert und unterstützt mobile Plattformen nicht offiziell.
Ein weiterer Aspekt ist die Wartung. Die einheitliche Laufzeitumgebung von Electron vereinfacht Kompatibilitätstests, verlangt von Anwendungsentwicklern aber auch, die mitgelieferten Chromium-Versionen zu pflegen und zu aktualisieren. Tauri überträgt mehr dieser Verantwortung auf das Betriebssystem, was den Wartungsaufwand für bestimmte Anwendungen verringern kann. Allerdings müssen Entwickler möglicherweise zusätzlichen Aufwand betreiben, um verschiedene Webview-Implementierungen zu testen und plattformspezifische Probleme zu lösen.
Der gesamte Entwicklungsaufwand ist wichtiger als jeder einzelne Benchmark. Ein Framework, das Arbeitsspeicher spart, aber deutlich mehr Entwicklungsarbeit erfordert, ist für ein bestimmtes Team möglicherweise nicht die effizienteste Wahl. Ebenso kann es unnötig sein, eine große Chromium-Laufzeitumgebung für ein einfaches Hilfsprogramm auszuliefern, wenn Tauri dieselbe Aufgabe mit weniger Ressourcen erledigen kann.
Electron vs. Tauri: Welches sollten Sie wählen?
Beide Frameworks eignen sich zur Entwicklung produktionsreifer Desktop-Anwendungen, sind jedoch auf unterschiedliche Prioritäten ausgerichtet.
| Ihre Priorität | Besserer Ausgangspunkt | Warum |
|---|---|---|
| Geringe Download- und Installationsgröße | Tauri | Verwendet die System-Webview |
| Geringer grundlegender Ressourcenverbrauch | Tauri | Schlankes natives Backend |
| Einheitliches Rendering auf allen Desktop-Plattformen | Electron | Liefert dieselbe Chromium-Engine mit |
| Umfangreiche Node.js-Integration | Electron | Integrierte Node.js-Laufzeitumgebung |
| Rust-basierte native Funktionen | Tauri | Rust ist die primäre Backend-Sprache |
| Anzeige beliebiger Websites von Drittanbietern | Electron | Berechenbare Chromium-Umgebung |
| Komplexe Verwaltung von Browser-Sitzungen | Electron | Ausgereifte APIs für Sitzungen und Partitionen |
| Desktop- und Mobilentwicklung | Tauri | Offizielle Unterstützung für Desktop- und Mobilplattformen |
| Möglichst wenig browserübergreifende Kompatibilitätstests | Electron | Einheitliche Engine auf allen Desktop-Plattformen |
Dies sind allgemeine Empfehlungen und keine absoluten Regeln. Mit Electron lassen sich effiziente Anwendungen entwickeln, während Tauri auch als Grundlage anspruchsvoller Software dienen kann. Die bessere Wahl hängt von den Produktanforderungen und den vorhandenen Kenntnissen des Teams ab.
Für Teams, die anspruchsvolle Desktop-Anwendungen entwickeln, verdienen das etablierte Ökosystem und die bewährte Praxistauglichkeit von Electron ernsthafte Beachtung. Dass Microsoft, Slack, Discord und andere große Softwareentwickler es einsetzen, zeigt, dass das Framework anspruchsvolle Anforderungen im produktiven Einsatz erfüllen kann.
Tauri bietet dagegen eine überzeugende Alternative für Projekte, bei denen kleinere Binärdateien, ein geringerer grundlegender Ressourcenverbrauch, die Integration von Rust oder eine gemeinsame Desktop- und Mobilentwicklung im Vordergrund stehen.
Fazit
Die Debatte um Electron und Tauri wird oft auf einen einfachen Vergleich reduziert: Electron ist groß, Tauri ist klein. Der aussagekräftigere Unterschied besteht jedoch zwischen einer mitgelieferten, einheitlichen Laufzeitumgebung und einem schlanken Framework, das sich in die vom System bereitgestellten Webviews integriert.
Electron legt den Schwerpunkt auf plattformübergreifende Einheitlichkeit, die Integration in das JavaScript-Ökosystem und umfassende Kontrolle über Browserfunktionen. Tauri konzentriert sich auf kleinere Anwendungspakete, effiziente native Ausführung und eine engere Integration mit den Webviews des Betriebssystems.
Bei WebCatalog haben wir uns für Electron entschieden, ebenso wie viele große Softwareunternehmen für ihre Desktop-Anwendungen. Wir schätzen sein ausgereiftes Ökosystem, seine einheitliche Chromium-Laufzeitumgebung und seine umfangreichen Browserfunktionen. Diese Vorteile helfen uns, ein Produkt zu entwickeln und zu pflegen, das eine große Bandbreite an Websites auf mehreren Betriebssystemen unterstützt.
Das macht Tauri nicht zu einer schlechten Wahl. Bei leichtgewichtigen Hilfsprogrammen oder Anwendungen mit anderen Anforderungen können seine Vorteile die von Electron überwiegen.
Das beste Framework ist nicht zwangsläufig dasjenige mit der kleinsten ausführbaren Datei oder dem geringsten Arbeitsspeicherbedarf. Es ist dasjenige, mit dem Ihr Team Ihre Anwendung am effektivsten entwickeln, warten und verbessern kann.
