Im ersten Teil dieser Serie habe ich Electron und Tauri verglichen – beide nutzen Web-Technologien, aber mit unterschiedlichen Ansätzen. Electron bringt Chromium mit (schwer), Tauri nutzt den OS-WebView (leicht).
In diesem zweiten Teil schaue ich mir Flutter und GPUI an – zwei Frameworks, die komplett andere Wege gehen:
- Flutter rendert mit eigener Engine (Skia) – kein Browser nötig
- GPUI geht noch weiter: GPU-natives Rendering direkt über Metal/Vulkan/DirectX
Beide Ansätze versprechen native Performance – aber mit unterschiedlichen Trade-offs. Dieser Artikel zeigt, wann diese Frameworks Sinn machen und wie sie sich im direkten Vergleich zu Electron und Tauri schlagen.
Flutter: Ein komplett anderer Ansatz
Eigene UI-Engine statt Browser
Flutter kommt aus einer anderen Welt: Google entwickelte es ursprünglich für Mobile Apps (Android + iOS) – Desktop-Support kam später.
Der zentrale Unterschied:
| Electron/Tauri | Flutter |
|---|---|
| Nutzt Browser (HTML/CSS) | Eigene UI-Engine |
| DOM-Rendering | Canvas/Skia-Rendering |
| Web-Technologien | Dart-Sprache |
| WebView-Performance | Native-ähnliche Performance |
Wie funktioniert Flutter?
- Skia: 2D-Grafik-Engine (auch in Chrome verwendet)
- Flutter rendert jedes Pixel selbst
- Kein Browser, kein WebView, kein DOM
- UI wird direkt auf Canvas/GPU gezeichnet
Das bedeutet:
- Volle Kontrolle über jeden Frame
- Konsistentes Aussehen auf allen Plattformen
- Sehr gute Performance (60 FPS sind Standard)
Vorteile: Konsistenz und Performance
1. Konsistente UI auf allen Plattformen
Bei Electron/Tauri:
- UI sieht unterschiedlich aus (je nach Browser)
- CSS kann auf Windows anders aussehen als auf macOS
Bei Flutter:
- UI sieht exakt gleich aus
- Pixel-perfekt identisch auf allen Plattformen
- Design-Vorgaben (z.B. Figma) können 1 umgesetzt werden
2. Sehr gute Performance
Flutter ist für 60 FPS+ optimiert:
- Rendering direkt auf GPU
- Kein DOM-Overhead
- Hot Reload während Entwicklung
- Smooth Animationen sind einfach
Typische Flutter-App:
- 30-50 MB RAM im Idle
- 10-30 MB Bundle-Size
- Start in unter 1 Sekunde
3. Große Community, viele Pakete
Flutter hat ein riesiges Ökosystem:
- 40.000+ Pakete auf pub.dev
- Starke Mobile-Community (größer als Desktop)
- Viele UI-Komponenten verfügbar
- Gute Dokumentation
4. Reactive UI-Modell
Flutter nutzt ein reaktives Pattern:
- Ähnlich wie React (aber nicht identisch)
- State-Management mit Provider, Riverpod, Bloc
- Deklarative UI-Definition
class Counter extends StatefulWidget {
@override
_CounterState createState() => _CounterState();
}
class _CounterState extends State<Counter> {
int count = 0;
@override
Widget build(BuildContext context) {
return Column(
children: [
Text('Count: $count'),
ElevatedButton(
onPressed: () => setState(() => count++),
child: Text('Increment'),
),
],
);
}
}Nachteile: Größe und Plattform-Feeling
1. Größere App-Größen als native Apps
- Flutter-Runtime muss mitgeliefert werden
- Typisch: 15-30 MB für einfache Apps
- Bei vielen Assets/Dependencies: 50-100 MB
- Kleiner als Electron, größer als echte native Apps
2. UI fühlt sich manchmal „untypisch” für das OS an
Flutter rendert alles selbst → UI folgt nicht automatisch OS-Konventionen.
Beispiel:
- macOS: Nutzer erwarten native Menüs, Scrollverhalten, Fenster-Controls
- Flutter: Kann das nachbauen, fühlt sich aber oft leicht „off” an
Lösung: Flutter bietet Cupertino (iOS-Style) und Material (Android-Style) Widgets – aber echtes macOS/Windows-Feeling ist schwer. Mehr zu meinen Erfahrungen mit Flutter und nativen Plattformen in meinem Artikel über Flutter vs. iOS.
Meine Perspektive für Desktop-Anwendungen:
In meiner Praxis nutze ich Flutter verstärkt für Desktop-Anwendungen – und die Frage nach “nativem Look-and-Feel” ist für mich zweitrangig. Was zählt, ist das Ergebnis: Funktioniert die App? Ist sie performant? Kann ich sie schnell weiterentwickeln?
Bei Business-Anwendungen und internen Tools steht Funktionalität über Plattform-Konformität. Nutzer gewöhnen sich schnell an ein konsistentes UI-Design – egal ob es “typisch macOS” oder “typisch Windows” ist. Der Vorteil: Ich entwickle einmal und habe eine App, die auf allen Plattformen identisch funktioniert und aussieht. Kein plattformspezifisches Debugging, keine unterschiedlichen Verhaltensweisen.
Für Produktiv-Tools, die Ergebnisse liefern müssen, ist das ein klarer Gewinn.
3. Desktop noch nicht so ausgereift wie Mobile
Flutter Desktop ist seit 2021 stable – aber:
- Viele Packages sind nur für Mobile optimiert
- Desktop-spezifische Features (z.B. Menübars, System Tray) brauchen Plugins
- Community ist primär Mobile-fokussiert
4. Dart-Sprache
Dart ist nicht mainstream:
- Weniger Entwickler kennen es (im Vergleich zu JavaScript)
- Lernkurve für Web-Teams höher als bei Tauri
- Nicht so viele Jobs wie JavaScript/TypeScript
Wo Flutter heute am stärksten eingesetzt wird
Mobile-First mit Desktop als Bonus:
Viele Unternehmen nutzen Flutter so:
- Primär für iOS + Android (ein Codebase statt zwei)
- Desktop-Version als Add-on mit wenig Extra-Aufwand
Beispiele:
- Google Ads (Mobile + Desktop)
- Alibaba (E-Commerce-Apps)
- BMW (Connected Car App)
- eBay Motors (Teilweise)
Wo Flutter glänzt:
- Consumer-Apps mit viel UI (E-Commerce, Social, Media)
- Design-heavy Apps (Custom UI, Branding)
- Cross-Platform Mobile + Desktop aus einem Codebase
Wo Flutter schwächelt:
- Productivity-Tools (fühlen sich oft nicht „native” an)
- OS-Integration (Menüs, System Tray, Keyboard Shortcuts)
- Web-Frontend-Reuse (kannst du nicht – Dart statt JavaScript)
Stark für UI-lastige Apps, weniger für Desktop-First
Flutter ist eine exzellente Wahl für:
✅ Mobile-First-Projekte, die auch Desktop wollen
✅ Apps mit starkem UI/UX-Fokus
✅ Teams, die volle Kontrolle über Rendering wollen
Weniger geeignet für:
❌ Desktop-First-Apps mit typischen OS-Interaktionen
❌ Teams, die bestehenden Web-Code wiederverwenden wollen
❌ Projekte, die sehr native macOS/Windows-Feeling brauchen
Meine Erfahrung mit Flutter:
Von allen Cross-Platform-Frameworks habe ich mit Flutter die meiste Praxiserfahrung. Ich habe bereits mehrere Anwendungen damit realisiert und bin sehr zufrieden mit der Performance und der plattformübergreifenden Entwicklung. Die Entwickler-Experience ist gut, Hot Reload macht die Entwicklung produktiv, und die Konsistenz über alle Plattformen hinweg ist ein echter Vorteil. Für UI-lastige Projekte mit Mobile-Fokus ist Flutter aus meiner Sicht aktuell unschlagbar.
GPUI: Der neue Herausforderer aus der Rust-Welt
Hintergrund: Zed-Editor-Team
GPUI ist das UI-Framework hinter Zed, einem modernen Code-Editor, der als “schnellster Editor der Welt” antritt.
Das Problem, das Zed lösen wollte:
- VSCode (Electron): Zu langsam, zu viel RAM
- Native macOS-Apps (z.B. Xcode): Nicht cross-platform
- Existierende Rust-UI-Frameworks: Zu unreif oder zu limitiert
Die Lösung: GPUI bauen
Das Zed-Team entwickelte ihr eigenes Framework – und machte es Open Source.
Die Kernidee:
- Rendering direkt über GPU (via wgpu)
- Kein Browser, kein WebView
- React-ähnliches UI-Modell – aber in Rust
- Performance wie native Apps – aber cross-platform
Architektur: Hybrid aus Immediate- und Retained-Mode
GPUI nutzt wgpu, eine Rust-Bibliothek für GPU-Zugriff:
- wgpu abstrahiert moderne Graphics APIs (Vulkan/Metal/DirectX)
- GPUI rendert UI-Elemente direkt auf die GPU
- Hybrid-Ansatz: Kombiniert Immediate-Mode (flexibel) und Retained-Mode (performant)
- Kein Browser-Overhead, keine WebView
Plattform-Status:
- macOS: Produktionsreif (Metal)
- Linux: Im Aufbau (Vulkan)
- Windows: Im Aufbau (DirectX)
Der Fokus liegt aktuell klar auf macOS, andere Plattformen folgen.
Was bedeutet das praktisch?
| Electron/Tauri | Flutter | GPUI |
|---|---|---|
| Browser rendert | Skia rendert | Direkt GPU |
| DOM-Baum | Widget-Tree | Element-Tree |
| CSS-Styling | Dart-Widgets | Rust-Components |
Vorteil gegenüber anderen Rust-UI-Frameworks (z.B. egui):
- Deutlich mehr Flexibilität
- Besser für große, komplexe Anwendungen
- Aber: Steilere Lernkurve
Vorteile: Extrem schlank und schnell
1. Minimale Bundle-Size
- 8-15 MB (Electron = 200 MB, Tauri = 10 MB)
- Nur Rust-Binary, kein Browser, keine Runtime
2. Sehr niedriger RAM-Verbrauch
Zed Editor vs. VSCode (gleiche Projekte):
- Zed (GPUI): 50-100 MB RAM
- VSCode (Electron): 300-800 MB RAM
3. Native Performance
- Startup: Unter 500ms
- Rendering: 120 FPS auf High-Refresh-Displays
- Responsiv auch bei komplexen Layouts
4. React-ähnliches UI-Modell
Deklarativ und komponentenbasiert – aber in Rust:
fn render(&mut self, cx: &mut ViewContext<Self>) -> impl IntoElement {
div()
.flex()
.flex_col()
.child(
h1().text("Hello GPUI")
)
.child(
button()
.on_click(|_, cx| {
println!("Button clicked");
})
.child("Click me")
)
}Ähnlich wie React, aber mit Type-Safety und direktem GPU-Rendering (kein Virtual DOM).
5. Component-Ökosystem (shadcn/ui-ähnlich)
Styling über Rust-Code, ähnlich Tailwind-Klassen:
use gpui::*;
button()
.bg(colors::blue_500)
.text_color(colors::white)
.px_4()
.py_2()
.rounded_md()
.on_click(|_, cx| {
// Action
})
.child("Submit")6. Hybrid-Ansatz möglich
GPUI kann WebViews einbetten – praktisch für Migration von bestehenden Web-Apps oder Legacy-Code-Integration.
Potenzial und Limitierungen
Warum GPUI spannend ist:
- Performance auf Native-Niveau, aber cross-platform
- Bundle-Size konkurriert mit nativen Apps (8-15 MB)
- Moderne Developer-Experience (React-ähnlich, type-safe)
- Rust-Ökosystem wächst rasant
Aktuelle Herausforderungen:
- Sehr jung – seit 2023 öffentlich, aktiv in Entwicklung
- Kleine Community – deutlich kleiner als Electron/Tauri/Flutter
- Lernkurve – Rust + GPU-Konzepte schwieriger als JavaScript/Dart
- Ökosystem – wenige Third-Party-Komponenten (aber wachsend)
- Plattform-Support – macOS produktionsreif, Linux/Windows folgen
Positiv:
- Zed Editor beweist: Produktionsreif für große Projekte
- Community wächst durch steigende Rust-Popularität
- Performance-Vorteil ist signifikant messbar
GPUI könnte das Framework für die nächste Generation werden – wenn es kritische Masse erreicht.
Meine Einschätzung zu GPUI:
GPUI ist für mich das spannendste Framework in diesem Vergleich – und gleichzeitig das größte Fragezeichen. Ich bin begeisterter Nutzer von Zed, dem Editor, der mit GPUI gebaut wurde, und die Performance ist beeindruckend. Als großer Rust-Fan (mehr dazu in meinem Artikel über Rust) arbeite ich mich gerade in GPUI ein.
Die große Frage: Könnte GPUI für mich ein würdiger Nachfolger für Flutter werden? Das würde voraussetzen, dass das Ökosystem wächst und die Community größer wird. Aber das Potenzial ist definitiv da – GPU-natives Rendering mit der Sicherheit und Performance von Rust könnte tatsächlich die nächste Generation von Cross-Platform-Frameworks definieren. Ich bin gespannt, wie sich GPUI in den nächsten 1-2 Jahren entwickelt.
Vergleich aller vier Frameworks
Leistung & Ressourcen
Bundle-Size:
GPUI: 8-15 MB ████░░░░░░░░░░░░░░░░
Tauri: 10-20 MB █████░░░░░░░░░░░░░░░
Flutter: 20-40 MB ██████████░░░░░░░░░░
Electron: 180-250 MB ████████████████████RAM-Verbrauch (Idle):
GPUI: 50-100 MB ████░░░░░░░░░░░░░░░░
Flutter: 80-150 MB ██████░░░░░░░░░░░░░░
Tauri: 100-200 MB ████████░░░░░░░░░░░░
Electron: 300-600 MB ████████████████░░░░Startup-Zeit:
GPUI: unter 0.5s ███░░░░░░░░░░░░░░░░░░
Flutter: unter 1s ██████░░░░░░░░░░░░░░░
Tauri: 1-2s ████████████░░░░░░░░░
Electron: 2-4s ████████████████████░Performance-Ranking:
- GPUI – GPU-nativ, minimal overhead
- Flutter – Eigene Engine, optimiert
- Tauri – WebView-abhängig, aber klein
- Electron – Chromium-overhead, langsam
UI-Paradigma
Electron/Tauri: Browser-basiert
- HTML/CSS/JavaScript
- DOM-Rendering
- Bekannt für Web-Entwickler
- Performance durch Browser limitiert
Flutter: Eigene Engine
- Dart + Widget-System
- Canvas/Skia-Rendering
- Konsistent über Plattformen
- Volle Kontrolle, aber nicht-nativer Look
GPUI: GPU-Rendering, keine WebView
- Rust + Element-System
- Direkt GPU via wgpu
- React-ähnlich, aber type-safe
- Native Performance, moderne DX
Ökosystem & Community
Community-Größe (GitHub Stars, Packages, Jobs):
| Framework | GitHub Stars | Packages | Jobs |
|---|---|---|---|
| Electron | 110k+ | npm (~2M) | Sehr viele |
| Flutter | 160k+ | 40k+ | Viele |
| Tauri | 75k+ | Wachsend | Mittel |
| GPUI | 8k+ | Klein | Wenige |
Reifegrad:
- Electron – Sehr ausgereift, seit 2013
- Flutter – Ausgereift (Mobile), Desktop seit 2021 stable
- Tauri – Reif genug für Production, seit 2020
- GPUI – Jung, aber produktionsreif (Zed läuft darauf)
Lernressourcen:
- Electron: Sehr viele (Tutorials, Kurse, Bücher)
- Flutter: Sehr viele (vor allem Mobile)
- Tauri: Gute Docs, wachsende Community
- GPUI: Wenig – hauptsächlich Zed-Sourcecode + Docs
Wann welches Framework?
Electron – Für bestehende Web-Apps und schnelle Prototypen
✅ Du hast bereits ein Web-Frontend (React, Vue, etc.)
✅ Team kann Web, aber nicht Rust/Dart
✅ Performance ist nicht kritisch (interne Tools)
✅ Du brauchst schnelle Time-to-Market
❌ Bundle-Size oder RAM sind limitierend
❌ App soll auf schwacher Hardware laufen
Tauri – Für moderne Web-Teams, die Electron-Nachteile vermeiden wollen
✅ Du willst Web-Technologien nutzen (HTML/CSS/JS)
✅ Bundle-Size und Performance sind wichtig
✅ Sicherheit ist kritisch
✅ Team ist offen für Rust-Backend
❌ Du brauchst vollständige Kontrolle über Rendering
❌ App ist sehr GPU-intensiv
Flutter – Für UI-lastige Apps, besonders Mobile + Desktop
✅ Du entwickelst primär für Mobile, Desktop ist Bonus
✅ UI soll auf allen Plattformen identisch aussehen
✅ Viel Custom-UI, Animationen, Design-Focus
✅ Team kann Dart lernen oder kennt es bereits
❌ Du brauchst nativen macOS/Windows-Look-and-Feel
❌ Du willst bestehenden Web-Code wiederverwenden
GPUI – Für neue Projekte mit Fokus auf Performance und Rust-Stack
✅ Du startest ein neues Projekt (kein Legacy-Code)
✅ Performance und Ressourcen-Effizienz sind Top-Priorität
✅ Team kann Rust oder ist bereit zu lernen
✅ Du brauchst native-ähnliche Performance
❌ Du brauchst ein großes Ökosystem (viele Packages)
❌ Zeit-to-Market ist kritisch (steile Lernkurve)
Zukunftsausblick
Browser-basierte Frameworks werden bleiben – aber verlieren an Vorsprung
Electron und Tauri werden nicht verschwinden. Zu viele Apps basieren darauf, zu viele Teams kennen Web-Technologien.
Aber:
Der Performance-Gap zu nativen Apps wird weniger akzeptabel:
- Nutzer erwarten schnelle Apps
- Laptops sollen länger laufen
- RAM wird nicht unbegrenzt größer
Die Entwicklung:
- Electron: Wird langsam durch Tauri ersetzt
- Tauri: Wird Standard für Web-basierte Desktop-Apps
- Browser-Frameworks: Bleiben dominant, aber nicht mehr konkurrenzlos
GPU-native Frameworks wie GPUI könnten die nächste Generation anführen
GPUI zeigt, was möglich ist:
- Native Performance
- Minimale Resources
- Moderne Developer Experience
Wenn GPUI (oder ähnliche Frameworks) kritische Masse erreichen:
- Könnte neuer Standard für Desktop werden
- Ähnlich wie React das Web-Development verändert hat
- Performance-first statt Web-first
Andere GPU-native Frameworks im Rust-Ökosystem:
- egui – Immediate-Mode-GUI, sehr einfach
- Iced – Elm-inspiriert, deklarativ
- Dioxus – React-ähnlich, auch für Web
GPUI ist aktuell am weitesten für Production-Apps.
Rust gewinnt in der Cross-Platform-Welt massiv an Einfluss
Warum Rust?
- Performance wie C/C++
- Sicherheit durch Compiler
- Moderne Tooling (Cargo)
- Wachsende Community
Rust-Frameworks dominieren die neuen Ansätze:
- Tauri: Rust-Backend
- GPUI: Voll Rust
- Dioxus: Rust
- Iced: Rust
Das bedeutet:
- Web-Entwickler müssen sich entscheiden: Weiter Web-Technologien (Tauri) oder Rust lernen (GPUI)?
- Teams mit Rust-Expertise haben einen Vorteil
- Universities und Bootcamps beginnen Rust zu lehren
Entwickler haben heute mehr Auswahl als je zuvor
Vor 5 Jahren:
- Electron oder native Apps (C++, Swift, etc.)
- Wenig Alternativen
Heute:
- Electron (Web-Technologien, schwer)
- Tauri (Web-Technologien, leicht)
- Flutter (Dart, eigene Engine)
- GPUI (Rust, GPU-nativ)
- Native (Swift, Kotlin, C++)
Die richtige Wahl hängt ab von:
- Team-Skills
- Performance-Anforderungen
- Zielplattformen
- Legacy-Code
- Time-to-Market
Es gibt kein „One size fits all” mehr.
Die Entscheidung hängt stark vom Projektkontext ab
Cross-Platform ist nicht mehr eine Technologie – es ist ein Spektrum.
Die Fragen, die du stellen solltest:
- Haben wir bereits einen Web-Frontend? → Electron/Tauri
- Ist Performance kritisch? → GPUI/Flutter
- Brauchen wir Mobile + Desktop? → Flutter
- Können wir Rust lernen? → Tauri/GPUI
- Ist Time-to-Market wichtiger als Performance? → Electron
- Wollen wir für die nächsten 10 Jahre bauen? → GPUI/Flutter
Drei typische Szenarien:
Szenario 1: Startup mit Web-App, will Desktop-Version
→ Tauri
- Bestehender React-Code wiederverwendbar
- Schneller Launch
- Kleine Bundle-Size für Updates
Szenario 2: Produktfirma baut neue Consumer-App (Mobile + Desktop)
→ Flutter
- Ein Codebase für iOS, Android, Desktop
- Custom UI/UX wichtig
- Große Community
Szenario 3: Entwickler-Tool (Editor, Terminal, Profiler)
→ GPUI
- Performance ist kritisch
- Nutzer sind technik-affin (akzeptieren neue Technologie)
- Rust-Ökosystem passt gut
Langfristig:
Wir werden wahrscheinlich eine Konsolidierung sehen:
- Electron wird langsam ersetzt
- Tauri wird Standard für Web-basierte Apps
- GPUI oder ähnliche Frameworks werden Standard für Performance-kritische Apps
- Flutter bleibt dominant für Mobile-first
Die nächsten 3-5 Jahre werden zeigen, welches Framework sich durchsetzt. Aktuell ist die spannendste Entwicklung: Rust-basierte Frameworks holen massiv auf.
Electron hat Desktop-Apps demokratisiert – aber die nächste Generation wird schneller, leichter und effizienter sein.