Die Art, wie wir Desktop-Anwendungen bauen, hat sich grundlegend verändert – weg von nativen C++ oder Swift-Apps, hin zu Cross-Platform-Lösungen, die auf Windows, macOS und Linux laufen. Lange Zeit war Electron die einzige ernsthafte Option. Doch die Landschaft hat sich dramatisch weiterentwickelt.
In dieser zweiteiligen Serie schaue ich mir die wichtigsten Cross-Platform-Frameworks an: Electron und Tauri (Teil 1), sowie Flutter und GPUI (Teil 2). Jeder Ansatz hat andere Stärken – und andere Trade-offs.
Dieser erste Teil zeigt, wo Electron an seine Grenzen stößt und warum Tauri für viele Projekte die bessere Alternative ist.
Warum Cross-Platform immer wichtiger wird
Vor zehn Jahren bedeutete Desktop-Entwicklung: Drei separate Apps für Windows, macOS und Linux schreiben. Drei Codebases, drei UI-Toolkits, dreifacher Aufwand. Das war für viele Teams schlicht nicht machbar.
Web-Technologien haben das geändert:
- Electron brachte JavaScript + HTML + CSS auf den Desktop
- VSCode, Slack, Discord, Figma – alles Electron-Apps
- Plötzlich konnten Webentwickler Desktop-Apps bauen
Das Problem: Electron ist schwer geworden.
- 200+ MB Bundlegröße für „Hello World”
- 500 MB RAM für einfache Apps
- Langsame Startup-Zeiten
- Energie-ineffizient (wichtig für Laptops)
Die Frage ist nicht mehr „Web oder Native?”, sondern: „Welches Cross-Platform-Framework passt zu meinem Projekt?”
Electron: Der alte Platzhirsch – und seine Grenzen
Warum Electron so erfolgreich wurde
Electron war 2013 revolutionär: GitHub (damals) wollte ihren Editor Atom plattformübergreifend machen – ohne drei separate native Apps zu schreiben.
Die Idee war genial einfach:
- Bündel Chromium (Browser-Engine) + Node.js (Backend)
- Entwickler schreiben HTML/CSS/JavaScript
- Läuft auf Windows, macOS, Linux – identisch
Das Versprechen:
- Wiederverwendung: Bestehende Web-Skills, bestehender Code
- Geschwindigkeit: Keine neue Technologie lernen
- Ökosystem: npm-Pakete, React, Vue, etc. einfach nutzen
Das Ergebnis:
Electron wurde zum Standard für Cross-Platform-Desktop. Heute basieren darauf:
- VSCode (Microsofts Code-Editor)
- Slack (Kommunikations-Tool)
- Discord (Gaming-Chat)
- Figma (Design-Tool – Desktop-Version)
- Notion (Notizen/Produktivität)
- Obsidian (Markdown-Editor)
Die bekannten Nachteile
Was anfangs praktisch war, wurde zum Problem:
1. Bundlegrößen:
- Eine simple „Hello World”-App: ~200 MB
- Grund: Jede App bringt Chromium mit
- Zum Vergleich: Native App = 5-20 MB
2. RAM-Verbrauch:
- VSCode im Idle: 300-500 MB RAM
- Slack: 400-800 MB RAM
- Mehrere Electron-Apps = GB an RAM weg
3. Startup-Zeiten:
- Chromium muss booten
- Node.js muss starten
- Erst dann läuft die App
- Spürbar langsamer als native Apps
4. Energie-Effizienz:
- Browser-Engine ist generisch optimiert
- Nicht spezifisch für Desktop-Workloads
- Laptops leiden unter kürzerer Akkulaufzeit
5. Sicherheit:
- Voller Node.js-Zugriff im Renderer-Prozess (früher)
- Viele Electron-Apps hatten RCE-Lücken
- Heute besser, aber immer noch komplex
Wann Electron trotzdem sinnvoll ist
Trotz aller Kritik: Für manche Teams ist Electron weiterhin die richtige Wahl.
Electron macht Sinn, wenn:
✅ Großes bestehendes Web-Frontend: Du hast bereits eine React/Vue/Angular-App und willst sie als Desktop-Version anbieten
✅ Team-Skills: Dein Team kann Web, aber nicht Rust oder Dart
✅ Schnelle Time-to-Market: Du brauchst schnell eine Desktop-App ohne neue Technologie lernen zu müssen
✅ Interne Tools: RAM und Bundle-Size sind nicht kritisch (z.B. Admin-Panels, interne Dashboards)
✅ Reifes Ökosystem: Du brauchst Zugriff auf tausende npm-Pakete
Electron macht keinen Sinn, wenn:
❌ Performance und Ressourcen-Effizienz kritisch sind
❌ Die App auf älteren/schwächeren Geräten laufen muss
❌ Kleine Bundle-Größen wichtig sind (Distribution, Updates)
❌ Du von Grund auf neu entwickelst (dann lohnt sich ein modernerer Stack)
Stabil, aber technisch schwerfällig geworden
Electron hat Cross-Platform-Desktop demokratisiert. Für viele Projekte war es die einzige realistische Option. Aber die Technologie ist in die Jahre gekommen:
- Chromium + Node.js sind schwer
- Moderne Alternativen sind deutlich effizienter
- Für neue Projekte gibt es oft bessere Optionen
Electron bleibt relevant – aber nicht mehr alternativlos.
Meine Erfahrung mit Electron:
Ich habe früher mit Electron gearbeitet und kann die Performance-Probleme aus erster Hand bestätigen. Die Bundle-Größen und der RAM-Verbrauch waren schon damals ein Thema – und haben sich seitdem nicht verbessert. Trotzdem: Electron war der Initiator dieser Cross-Platform-Bewegung und hat gezeigt, dass Desktop-Apps mit Web-Technologien funktionieren können. Dafür gebührt dem Framework Respekt, auch wenn ich es heute nicht mehr einsetzen würde.
Tauri: Der moderne, schlanke Electron-Ersatz
Grundidee: Rust-Backend + Web-Frontend
Tauri (seit 2020) verfolgt einen ähnlichen Ansatz wie Electron – aber ohne den Ballast.
Der Kernunterschied:
| Electron | Tauri |
|---|---|
| Bringt Chromium mit | Nutzt OS-eigenen WebView |
| Node.js als Backend | Rust als Backend |
| ~200 MB Bundle | ~5-15 MB Bundle |
| ~300-500 MB RAM | ~50-150 MB RAM |
Die Idee:
- Frontend: HTML/CSS/JavaScript (wie bei Electron)
- Backend: Rust (statt Node.js)
- Rendering: Betriebssystem-WebView (statt Chromium)
Was bedeutet „OS-eigener WebView”?
- macOS: WKWebView (Safari-Engine)
- Windows: WebView2 (Edge/Chromium)
- Linux: WebKitGTK
Statt Chromium mitzuliefern, nutzt Tauri den Browser, der bereits im System ist.
Vorteile: Klein, schnell, sicher
1. Sehr kleine Bundlegrößen
Eine Tauri-App ist typischerweise:
- 5-15 MB (statt 200+ MB bei Electron)
- Updates sind schneller
- Distribution ist einfacher
- Ideal für Deployment über Netzwerk
2. Deutlich weniger RAM
Tauri-Apps verbrauchen oft:
- 50-150 MB RAM im Idle (statt 300-500 MB)
- Mehrere Tauri-Apps = immer noch weniger als eine Electron-App
3. Sicherheit durch Rust
Rust verhindert ganze Klassen von Bugs:
- Keine Null-Pointer
- Keine Race Conditions
- Keine Memory Leaks
- Sehr schwer, unsicheren Code zu schreiben
Tauri hat zusätzlich ein Capability-System:
- Frontend hat standardmäßig keinen Dateisystem-Zugriff
- Jede Permission muss explizit gewährt werden
- Deutlich sicherer als Electrons Standardkonfiguration
4. Reuse moderner Web-Frameworks
Du kannst weiterhin nutzen:
- React, Vue, Svelte, Solid
- Tailwind, CSS-in-JS
- Vite, Webpack, Turbopack
- npm-Ökosystem
Für Web-Entwickler: Fast keine Lernkurve.
Praxisbeispiele
Wer nutzt Tauri heute?
- Cap (Open-Source Loom-Alternative für Screen-Recordings)
- screenpipe (AI-App-Plattform basierend auf Screen & Audio-Context)
- ChatGPT Desktop (inoffizielle Desktop-Apps)
- Jellyfin Vue (GUI-Client für Jellyfin Media Server)
- Viele Open-Source-Tools und kleinere Anwendungen
Tauri ist noch relativ jung (v1.0 seit 2022, v2.0 seit 2024), daher gibt es bisher weniger große kommerzielle Anwendungen als bei Electron. Die Community wächst aber rasant.
Typischer Use Case:
Ein SaaS-Unternehmen hat eine React-basierte Web-App und will eine Desktop-Version:
- Frontend-Code zu 90% wiederverwendbar
- Backend in Rust für native Features (Dateisystem, Notifications, etc.)
- Bundle ist 10-20 MB statt 200 MB
- Schneller, effizienter, sicherer als Electron
Grenzen: Immer noch WebView-basiert
Tauri ist nicht perfekt. Die WebView-Abhängigkeit bringt Trade-offs:
1. UI-Performance abhängig vom Browser
- Rendering-Performance ist limitiert durch WebView
- Kein Control über Browser-Engine
- Komplexe Animationen können ruckeln
- GPU-intensive UI (z.B. 3D) ist schwierig
2. Inkonsistenzen zwischen Plattformen
- macOS nutzt Safari-Engine (WebKit)
- Windows nutzt Edge (Chromium)
- Linux nutzt WebKitGTK
Resultat: Gleicher Code kann unterschiedlich aussehen oder sich anders verhalten.
3. Abhängigkeit von System-Browser
- Alte Windows-Versionen: Kein WebView2 vorinstalliert
- User muss WebView2 nachinstallieren (zusätzlicher Schritt)
- Auf Linux: Abhängigkeit von WebKitGTK-Version
4. Keine vollständige Kontrolle über Rendering
- WebView ist eine Blackbox
- Optimierungen auf Browser-Ebene sind nicht möglich
- Für sehr performante UIs limitierend
Beste Wahl für Web-Teams, die Electron-Nachteile vermeiden wollen
Tauri ist für viele Projekte die bessere Alternative zu Electron:
- Deutlich kleiner und schneller
- Sicherer durch Rust
- Weiterhin Web-Technologien nutzbar
Ideal für:
- Teams mit Web-Expertise
- Projekte, die Electron-Bundle-Size reduzieren wollen
- Apps, die nicht GPU-intensiv sind
Nicht ideal für:
- Sehr hohe Performance-Anforderungen (3D, Games, komplexe Animationen)
- Projekte, die vollständige Kontrolle über Rendering brauchen
Meine Erfahrung mit Tauri:
Tauri war für mich das Framework, das ich mir angeschaut habe für den Fall, dass ich noch mal etwas in Richtung Electron hätte machen müssen. Ich habe erste Erfahrungen damit gesammelt und war beeindruckt von der kleinen Bundle-Size und der Performance. Leider hatte ich bisher noch kein Kundenprojekt, bei dem ich Tauri produktiv einsetzen konnte – aber wenn es so weit ist, wäre Tauri definitiv meine erste Wahl.
Zwischenfazit: Browser-basiert, aber unterschiedlich schwer
Sowohl Electron als auch Tauri setzen auf Web-Technologien – aber mit unterschiedlichen Ansätzen:
Electron:
- ✅ Sehr ausgereift, riesiges Ökosystem
- ✅ Konsistent über alle Plattformen (eigener Browser)
- ❌ Schwer (200+ MB), langsam, hoher RAM-Verbrauch
Tauri:
- ✅ Sehr klein (5-15 MB), schnell, sicher
- ✅ Web-Technologien weiterhin nutzbar
- ❌ WebView-abhängig, mögliche Plattform-Inkonsistenzen
Für neue Projekte ist Tauri in den meisten Fällen die bessere Wahl – es sei denn, du brauchst absolute Plattform-Konsistenz oder das riesige Electron-Ökosystem.