Web-App oder Desktop-Anwendung? Eine Entscheidungshilfe

Bevor du die erste Zeile Code schreibst, triffst du eine Entscheidung, die schwer rückgängig zu machen ist: Wird das eine Web-App oder eine Desktop-Anwendung? Die Antwort fühlt sich oft offensichtlich an, bis man genauer hinschaut. Heute gibt es PWAs, die fast so reichhaltig sind wie Desktop. Es gibt Electron-Apps, die im Grunde Browser im Pelz sind. Es gibt native Apps, die jedes Betriebssystem perfekt nutzen. Und es gibt Tauri, das versucht, aus jeder Welt das Beste mitzunehmen. Diese Übersicht hilft dir, die richtige Wahl zu treffen.

Was Web-Apps können — und wo sie aufhören

Eine Web-Anwendung läuft im Browser. Das hat Vorteile, die schwer zu schlagen sind. Keine Installation, kein Update-Mechanismus — jeder Nutzer hat immer die aktuelle Version. Plattformunabhängig: dasselbe Frontend bedient Windows, Mac, Linux, iOS, Android und ChromeOS. Zentrale Wartung: ein Bug-Fix erreicht in Minuten alle Nutzer.

Was Web-Apps lange nicht konnten, war hardware-naher Zugriff. Datei-System nur über Datei-Picker, kein direkter Zugriff. USB nicht. Bluetooth nicht. Hintergrund-Tasks beim Schließen des Tabs vorbei. Das hat sich mit modernen Web-APIs verändert: WebUSB, WebBluetooth, File System Access API, Service Worker für Hintergrund-Sync. Eine PWA mit installierter Variante kommt heute näher an Native heran als es früher denkbar war.

Aber: Diese APIs sind nicht überall verfügbar. WebUSB läuft auf Chromium, nicht auf Safari. File System Access ist auf macOS in Safari weiterhin eingeschränkt. Wer professionell auf bestimmte Hardware angewiesen ist — Drucker, Scanner, Kassen-Bondrucker, EC-Cash-Terminals —, läuft mit Web schnell ans Limit. Da ist Native immer noch die ehrlichere Antwort.

PWA — die installierbare Web-App

Progressive Web Apps sind ein Mittelweg, der für viele Anwendungen die richtige Antwort ist. Eine PWA ist eine Web-Anwendung mit Manifest und Service Worker, die der Nutzer „installieren“ kann — was im Wesentlichen bedeutet, dass ein App-Icon angelegt wird und das Frontend offline funktioniert. Twitter Lite, Spotify Web, Notion — alles PWAs.

Was eine PWA gegenüber einer normalen Web-App gewinnt: Offline-Fähigkeit, Installations-Erlebnis, Push-Notifications, Hintergrund-Sync. Was sie nicht gewinnt: tiefen Zugriff auf das Betriebssystem. Wer wirklich native Performance braucht oder OS-spezifische Features, kommt mit PWA nur zur Hälfte ans Ziel.

Electron — die Browser-Variante

Electron ist der Versuch, Web-Technologien als Desktop-App zu liefern. Im Kern ist es ein Chromium-Browser plus Node.js, gebündelt mit deiner Anwendung. Slack, VS Code, Discord, Microsoft Teams — alle laufen auf Electron. Das hat den Vorteil, dass eine Codebase Windows, Mac und Linux abdeckt. Es hat den Nachteil, dass jede Electron-App rund 100 MB für den eingebauten Browser mitbringt, und entsprechend RAM frisst.

Electron hat seinen Platz, aber er ist begrenzt. Wer hochperformante Desktop-Anwendungen braucht, sollte ihn vermeiden. Wer eine Cross-Platform-Anwendung mit moderater Last und reichhaltigem UI bauen will, ist gut bedient. Wer es als bessere Alternative zu Webview-Embedding behandelt, ist auf dem richtigen Weg — nicht als Universallösung.

Tauri — der schlanke Rivale

Tauri ist die spannendste Entwicklung der letzten Jahre in dieser Ecke. Statt Chromium mitzuliefern, nutzt Tauri die system-eigene Webview — WebView2 unter Windows, WKWebView unter macOS, WebKitGTK unter Linux. Das macht Tauri-Anwendungen drastisch kleiner (oft unter 5 MB statt 100 MB) und sparsamer im RAM-Verbrauch. Das Backend läuft in Rust, was zusätzliche Performance und Sicherheit bringt.

Was Tauri schwerer macht als Electron: Die Webview-Unterschiede zwischen den Plattformen sind real. WebView2 ist Chromium-basiert, WKWebView ist Safari-basiert. Wer auf bleeding-edge-CSS-Features setzt, muss damit rechnen, dass etwas auf einer Plattform anders aussieht. Für die meisten Anwendungen ist das kein Problem, für aufwändige UIs schon.

Native — wenn es wirklich darauf ankommt

Native Apps werden für die jeweilige Plattform gebaut. WinUI 3 oder WPF unter Windows. SwiftUI oder AppKit unter macOS. GTK oder Qt unter Linux. Das ist mehr Aufwand, weil du pro Plattform eigenen Code schreibst, oder eine Cross-Platform-Lösung wie .NET MAUI, Flutter Desktop oder Qt nimmst, die zumindest die UI vereinheitlicht.

Wann lohnt sich Native? Wenn die Anwendung Performance kritisch ist (Audio-Workstations, Video-Editing, Spiele). Wenn tiefer Hardware-Zugriff nötig ist (Mediziner-Software mit USB-Geräten, Industrie-Steuerungen). Wenn das Betriebssystem-Look-and-Feel wichtig ist (Mac-Power-User merken Electron sofort). Wenn Performance bei großen Datenmengen entscheidet (Datenbank-Tools, große Tabellenkalkulationen).

Mein eigenes Projekt EchoPlay ist eine WinUI-3-Native-App. Der Grund: Audio-Wiedergabe mit niedriger Latenz, tiefer Zugriff auf das Datei-System und ID3-Tags von Audio-Dateien, ein UI, das sich auf Windows wie Teil des Systems anfühlt. All das wäre mit Electron oder Tauri möglich, aber teurer und holpriger. Native war hier die natürliche Wahl.

Die Entscheidungs-Faustregel

Frag dich drei Dinge, in dieser Reihenfolge. Erstens: Brauchst du tiefen Hardware-Zugriff oder OS-Integration? Wenn ja, wird es Native oder — mit Einschränkungen — Tauri. Zweitens: Wie wichtig ist die zentrale Wartung über alle Plattformen? Wenn extrem wichtig, ist Web oder PWA die richtige Antwort. Drittens: Wie viel RAM und Disk darf die Anwendung verbrauchen? Wenn das egal ist, kann Electron eine produktive Wahl sein. Wenn nicht, ist Tauri oder Native der Weg.

Eine Beobachtung aus den letzten Jahren: Viele Teams entscheiden sich aus Gewohnheit für Electron, weil sie Web-Stack beherrschen. Das ist okay, solange man die Folgen kennt — höherer RAM-Verbrauch, weniger native Look-and-Feel, höhere Update-Größen. Wer dabei langfristig wirtschaftlich bleiben will, sollte alle drei oder vier Jahre kritisch hinterfragen, ob die Architektur noch passt.

Die richtige Architektur ist nie die populärste, sondern die, die zu deinem Anwendungsfall passt. Eine Web-App, die nie wirklich offline-fähig sein muss, ist die einfachste Lösung. Eine native App für ein Audio-Studio ist die einzige sinnvolle. Alles dazwischen ist Trade-off-Arbeit.