Electron, Tauri oder Deno Desktop? Das CTO‑Playbook 2026 für KI‑intensive Apps

Wenn Ihr Produktteam es ernst meint mit KI, die tatsächlich auf den Rechnern der Nutzer läuft, sind Sie wieder im Desktop‑Geschäft. Die Web‑Sandbox kommt an die Hälfte der benötigten Hardware nicht heran. Mit HN, das über Deno Desktop diskutiert, und Anbietern, die im Wettlauf WebGPU, Vulkan 1.2, DirectML und Core ML zugänglich machen, wird 2026 aus „Electron vs Tauri“ eine Drei‑Wege‑Entscheidung — jetzt mit Deno und seinem Laufzeit‑Berechtigungsmodell im Mix.

Die unbequeme Wahrheit: Ihre Desktop‑Wahl bestimmt den Großteil Ihres Risikos — Sicherheit, Update‑Mechanik, GPU‑Zugang und Ihre Ship‑Geschwindigkeit. Dieser Beitrag liefert Ihnen ein CTO‑taugliches Entscheidungsframework, kein Fan‑Club‑Urteil.

Warum diese Entscheidung dringend ist

Drei Entwicklungen machen diese Wahl unausweichlich:

• Der Schwerpunkt hat sich auf lokale KI verlagert. Nach einem Jahr der Debatten à la „Es gibt kaum Nachteile beim Wechsel auf offene Modelle“ liefern viele Teams jetzt 3–7B offene Gewichte an den Edge für Latenz, Datenschutz und Kostentransparenz. Das bedeutet mehrere Gigabyte, GPU‑Bindings und echte Update‑Infrastruktur.
• GPU‑APIs sind gereift. Mit Mainstream‑Apps, die Vulkan 1.2 übernehmen, und einem stabilisierten WebGPU in Chromium‑basierten Stacks können Sie Inferenz und Bildpipelines ohne Zauberei auf die GPU der Nutzer auslagern.
• Sicherheit und Vertrauen haben angezogen. Nutzer, IT und Regulatoren achten sensibel auf Code‑Signierung, Notarisierung und darauf, wohin Ihre App „nach Hause telefoniert“. Ihr Updater und die Sandbox‑Einstellungen sind heute Teil Ihres Produktrufs.

Die drei Desktop‑Kandidaten 2026

Electron (Chromium + Node)

• Footprint: Installer üblicherweise 80–150 MB; Delta‑Updates können mit Block‑Map‑Strategien auf einstellige MB fallen.
• Speicher: Leerlauf: Renderer + Main typischerweise 150–300 MB, je nach Erweiterungen und DevTools‑Disziplin.
• GPU‑Pfad: Bester WebGPU‑Support kurzfristig (Chromium), plus gereifte Node‑API für native ML‑Backends (llama.cpp, ONNX Runtime, TensorRT‑Bindings).
• Sicherheitslage: Größte Angriffsfläche per Default, aber härtbar mit contextIsolation, deaktiviertem remote und strikt geregeltem IPC. Sandbox‑Renderer empfohlen.
• Update‑Mechanik: Ausgereift. Code‑Signierung + Notarisierung + Delta‑Updates sind gut eingefahren.

Tauri (Rust core + WebView)

• Footprint: Winzig. Installer oft im Bereich 5–20 MB, weil die System‑WebView wiederverwendet wird.
• Speicher: Häufig 50–120 MB im Leerlauf; kleinerer Prozessbaum als Electron.
• GPU‑Pfad: Sie greifen direkt zu Rust‑Crates und nativen ML‑Runtimes (llama.cpp, candle, ort). WebGPU in der System‑WebView ist uneinheitlicher als in Chromium, aber Rust‑seitige GPU ist stark über wgpu/Vulkan/Metal/DirectX.
• Sicherheitslage: Minimale Angriffsfläche von Haus aus. Command‑Allowlists, kein Node, weniger bewegliche Teile. Die nativen Grenzen kontrollieren Sie in Rust.
• Update‑Mechanik: Solide, signierte Updates über Plattformen hinweg, aber weniger „batteries included“ als im Electron‑Ökosystem.

Deno Desktop (emerging, Deno runtime + UI shell)

• Footprint: Frühe Berichte deuten auf Dutzende MB für das Runtime‑Bundle hin (kleiner als ein volles Chromium, größer als eine reine WebView‑Shell). Rechnen Sie mit Bewegung.
• Speicher: Vergleichbar mit anderen WebView‑Shells bei einfachen Apps; schwerer bei komplexer UI und Hintergrundaufgaben.
• GPU‑Pfad: Vielversprechend über WebGPU in der zugrunde liegenden Engine plus Denos FFI zu nativen Bibliotheken. Ökosystem noch am Reifen.
• Sicherheitslage: Starkes Berechtigungsmodell aus Deno übernommen (explizite allow-read, allow-net etc.). Gute Defaults für eine Least‑Privilege‑Haltung.
• Update‑Mechanik: Im Aufholen, aber noch nicht so schlüsselfertig wie die etablierte Electron‑Toolchain. Updater und Code‑Signierung früh in einem Spike validieren, bevor Sie sich festlegen.

Bestimmen Sie zuerst das Profil Ihrer App

Wählen Sie keine Runtime, bevor klar ist, was die App tatsächlich sein soll. Die meisten KI‑Desktop‑Produkte, die wir sehen, passen in eines dieser drei Profile:

1. Agent‑Konsole: Immer‑online‑UI, die Cloud‑Inferenz orchestriert, mit einigen lokalen Tools (Screen Capture, Tastatureingaben, System‑Prompts). Geringer lokaler Modelleinsatz, überwiegend UI/IPC und sichere Updates.
2. Offline‑Studio: Schwere lokale Inferenz (3–7B Modelle, Bild‑Pipelines, Embeddings) mit optionalem Cloud‑Sync. Modelle liegen auf der Platte; GPU‑Beschleunigung ist Pflicht.
3. Hybrides IDE/Notebook: Entwickler‑Erlebnis mit Plugins und lokalen Tools (Formatter, Linter, kleine Modelle) und gelegentlichen Cloud‑Aufrufen.

Bringen Sie Ihr Profil mit Ihren Randbedingungen in Einklang:

• Sicherheitskritisch? Sie treffen auf MDM‑Policies, Enterprise‑Code‑Signierungschecks und App‑Sandbox‑Regeln.
• GPU‑kritisch? Sie wählen native ML‑Backends und exponieren sie sicher über Ihre Runtime.
• Footprint‑kritisch? Distributionsgröße und Speicher zählen für Massenmarkt‑Nutzer und EDU/Behördenflotten.
• Team‑Skills? JS/TS‑lastig vs. Rust‑lastig lenkt Sie in unterschiedliche Richtungen.

Realitätscheck zu GPU und Model‑Runtimes

Es gibt viel WebGPU‑Euphorie. Verdient, aber richtig einzuordnen:

• Kleine/mittlere Modelle und Bild‑Ops: WebGPU in Electrons Chromium kann großartig sein für shader‑basierte Effekte und moderate Tensor‑Workloads. Erwarten Sie spürbare Beschleunigung auf integrierten GPUs.
• LLMs mit 3–7B bei 4‑Bit: Der praktikable Weg ist heute weiterhin native Backends, die Plattformbeschleuniger nutzen: DirectML auf Windows, Metal/Core ML auf macOS, CUDA auf NVIDIA, Vulkan via IREE oder ggmls Vulkan für Linux/AMD. WebGPU ist für große Modelle noch kein Allheilmittel.
• Plattformübergreifende Inferenzbibliothek: llama.cpp (GGUF/ggml‑Familie) bleibt die pragmatische Basis. Unterstützt Metal, CUDA, Vulkan und DirectML und lässt sich als statische oder dynamische Bibliothek ausliefern, die Sie aus Node‑API (Electron) oder Rust (Tauri) binden. Deno Desktop kann es via FFI ansprechen, aber den Kleber besitzen Sie.

Die Konsequenz: Ihre Runtime muss native Bindings langweilig machen — bauen, signieren, preloaden und updaten, ohne Nutzerrechner zu bricken.

Sicherheitslage: Der Ruf Ihrer App hängt davon ab

Härtung von Electron

• Node in Renderern deaktivieren, contextIsolation aktivieren, typisiertes IPC mit strikten Kanal‑Allowlists.
• Das remote‑Modul und dynamisches require im Renderer verbieten. Per contextBridge nur absolut Notwendiges per Preload exponieren.
• CSP erzwingen und alle URL‑Loads auditieren. Jede Drittanbieter‑UI wie nicht vertrauenswürdig behandeln.

Tauri‑Disziplin

• Business‑Logik in Rust‑Commands halten; UIs bleiben dumm. Least‑Privilege‑Command‑Allowlists.
• Jedes Crate prüfen; ein kompromittiertes Crate ist ein nativer Kompromiss.
• Dateizugriffe sandboxen und Netz‑Egress‑Domains nach Möglichkeit pinnen.

Deno Desktop‑Berechtigungen

• Die expliziten Berechtigungen von Deno (--allow-read, --allow-net, --allow-ffi) konsequent nutzen. Standardmäßig verweigern.
• Berechtigungen in Ihrer Einstellungs‑UI sichtbar machen; Vertrauen gewinnen, indem Sie genau zeigen, was und warum Sie nutzen.

Updates: die stille Ursache für Ausfälle

Die meisten Desktop‑Ausfälle sind Updater‑Eigenverschulden. Ihr Plan muss explizit sein:

• Signierung und Notarisierung: macOS erfordert Developer‑ID‑Signierung + Notarisierung; Windows braucht Authenticode und SmartScreen‑Reputation (ein EV‑Zertifikat beschleunigt das). Beides automatisieren.
• Delta‑Updates mit Rollback: Electrons Block‑Map‑Strategie senkt Updates oft auf 5–20 MB. Tauris Updater unterstützt signierte Diffs. Was immer Sie nutzen: automatisches Rollback implementieren, wenn die App nach einem Update nicht bootet.
• Model‑Gewichte sind keine App‑Updates: 3–7 GB Modelldateien nicht in Installer packen. Beim ersten Start herunterladen, HTTP‑Range‑Requests unterstützen, Checksummen verifizieren und in OS‑gerechten Caches ablegen. Drosseln und Fortschritt anzeigen. Modelle versionieren und per Garbage Collection räumen.
• Gestaffelte Rollouts: Zunächst 5–10% Canary. Ihr Updater sollte Kohorten respektieren, damit Sie fehlerhafte Builds schnell stoppen können.

Was Sie messen sollten (bevor Sie sich festlegen)

Führen Sie in jedem Kandidaten‑Stack einen zweiwöchigen Spike mit denselben Minimal‑Features durch:

• Ein 3–4 GB‑GGUF‑Modell laden, 60‑Sekunden‑Prompt ausführen, Tokens streamen, dann entladen. Tokens/s und End‑to‑End‑Latenz protokollieren.
• Kaltstartzeit nach frischem Boot erfassen und Leerlauf‑RSS nach 60 Sekunden, mit und ohne DevTools.
• Einen signierten Build an eine Testgruppe ausliefern und dann ein Delta‑Update pushen. Ausfallrate, Rollback‑Verhalten und aus Nutzersicht wahrgenommene Downtime messen.
• Den Inferenz‑Worker mitten im Lauf crashen. Verifizieren, dass die App überlebt und den Modellzustand wiederherstellt, ohne den Cache zu beschädigen.

Zahlen, die Entscheidungen in der Praxis bewegen:

• Installer‑Größe und Delta‑Größe: Beeinflusst Download‑Konversionen und Reibung bei Enterprise‑Deployments.
• Leerlauf‑Speicher: Sagt voraus, wie viele parallele Fenster/Tabs Sie unterstützen können, bevor Nutzer Sie für das „Langsame‑Maschine‑Syndrom“ verantwortlich machen.
• Tokens pro Sekunde auf repräsentativer Hardware: Auf einem 16 GB Mac der M‑Serie können 4‑Bit‑7B‑Modelle von einstelligen t/s (CPU) auf Dutzende t/s (GPU) springen — mit dem richtigen Backend. Validieren Sie das in Ihrem Stack.

Entscheidungsrahmen: bewusst wählen

Wenn Ihre App eine Agent‑Konsole ist und Ihr Team TS‑lastig

• Electron wählen für die nächsten 12 Monate. WebGPU ist hier voraus, das Ökosystem für Auto‑Updates und Code‑Signierung ist ausgereift, und Node‑API‑Bindings zu nativen Backends sind reichlich vorhanden.
• Leitplanken: Renderer als nicht vertrauenswürdig behandeln. Kein Node im Renderer, striktes IPC. Delta‑Updates mit Rollback nutzen. Alle Update‑Endpunkte pinnen.

Wenn Ihre App ein Offline‑Studio ist und Sie Rust staffen können

• Tauri wählen, wenn Footprint und Least‑Privilege zählen. Inferenz in Rust mit einem stabilen Crate (llama.cpp/candle/ort) halten und der UI nur minimale Commands exponieren.
• Leitplanken: 4–6 Wochen einplanen, um GPU‑Backends, binäre Paketierung pro Plattform und einen verlässlichen Updater zu meistern. Ihren Rust‑Core wie einen Backend‑Service behandeln — mit Logging und Crash‑Reporting.

Wenn Sie eine permissionierte Runtime wollen und Early‑Adopter‑Kanten akzeptieren

• Deno Desktop pilotieren für interne Tools und kontrollierte Rollouts. Das Berechtigungsmodell ist exzellent; das Ökosystem holt auf.
• Leitplanken: Updater, Signierung und Notarisierung früh spiken. Eine Exit‑Option zu Electron oder Tauri bereithalten, falls eine fehlende Integration Ihren Termin blockiert.

Referenzarchitekturen, die die Realität überstehen

Electron‑Referenz

• Main‑Prozess: Minimal. Keine Business‑Logik. Verantwortung für Lifecycle, Updates und sicheres IPC.
• Renderer: React/Svelte + WebGPU für leichte Compute und Visualisierung. contextBridge‑Preload exponiert ausschließlich eine typisierte API‑Oberfläche.
• Inference‑Worker: Native Module um llama.cpp oder ONNX Runtime mit einer begrenzten Schnittstelle. Vorgebaute Binärdateien pro Plattform/Arch mit Code‑Signierung ausliefern.
• Updates: S3‑kompatibles statisches Hosting mit signierten Manifesten und Block‑Map‑Deltas; 10% Canary, 1‑Klick‑Rollback.

Tauri‑Referenz

• Core: Rust orchestriert Inferenz, Storage und Dateizugriffe. Die UI sendet Commands; null Business‑Logik in JavaScript.
• GPU: Rust‑seitige ML‑Backends nutzen (llama.cpp via C‑FFI oder Rust‑Bindings; wgpu für eigene Kernel) und der UI Streaming‑Events bereitstellen.
• Updates: Tauris signierter Updater mit gestaffelten Kohorten. Modelle nach der Installation holen, checksummen, wiederaufnehmbar.

Deno Desktop‑Referenz

• Runtime: Deno‑Berechtigungsflags sind Ihre Default‑Policy. Die UI läuft in einer WebView; Business‑Logik steht hinter expliziten allow-*‑Gates.
• Native Calls: FFI zu einer kleinen C‑Schicht, die Ihr ML‑Backend kapselt. Die Grenze klein und geprüft halten.
• Updates: Updater früh validieren; falls unreif, einen signierten externen Bootstrapper implementieren, der die App atomar austauscht.

Team‑ und Kostenrealismus

• Electron‑POC: 2–3 erfahrene TS‑Ingenieure liefern in 2–3 Wochen einen glaubwürdigen, signierten POC inklusive einfachem Updater und kleinem lokalen Modell‑Demo.
• Tauri‑POC: 1 Rust‑ + 1 TS‑Ingenieur benötigen typischerweise 4–6 Wochen, um ein GPU‑beschleunigtes Backend zu integrieren, einen soliden Updater zu verdrahten und einen signierten Build auf macOS und Windows zu landen.
• Deno Desktop‑POC: Rechnen Sie mit 3–5 Wochen und mehr Risiko bei Updater und Bindings. Zunächst mit interner Zielgruppe pilotieren.

Staffing‑Hinweis: Brazil verfügt über tiefe Talentpools in Rust und TypeScript. Ein Nearshore‑Team mit 6–8 Stunden US‑Zeitzonen‑Überschneidung und 20–30% geringeren Fully‑Loaded‑Kosten als US‑Hires kann Ihr POC de‑risken, ohne es in einen jahrelangen Rewrite zu verwandeln.

Risiken, die Sie nicht ignorieren dürfen

• Supply Chain: Ihre größte Verwundbarkeit sind weiterhin Dependencies. Paketversionen einfrieren, Integritätsprüfungen nutzen und signierte, reproduzierbare Builds fahren. Native Crates und Node‑API‑Module prüfen wie einen Kernel‑Treiber.
• Plattendruck: Modell‑Caches werden anschwellen. Explizite Limits, LRU‑Eviction und eine klare UI für Speichersteuerung definieren. Write‑Amplification im Griff behalten; SSDs nicht mit unaufhörlichem Logging oder Chunk‑Rewrites malträtieren.
• Privacy und Daten­grenzen: Lokale Inferenz ist kein Freifahrtschein für Compliance. Telemetrie, Crash‑Dumps und gecachte Prompts können weiterhin PII enthalten. Löschung und Schwärzung in Ihr Produkt bauen — nicht in den Backlog.

Was wir jetzt empfehlen

• Wenn Sie dieses Quartal mit einem TS‑lastigen Team shippen, Electron wählen, härten und shippen. In 12 Monaten neu bewerten, falls der Footprint zur Top‑Beschwerde wird.
• Wenn Sie ein Flagship, offline‑first‑Studio mit starker GPU bauen und Rust staffen können, Tauri wählen und in Ihr natives ML‑Backend als First‑Class‑Modul investieren.
• Wenn Ihre Organisation strikte Berechtigungen und web‑standardisierte APIs schätzt und Sie einige rauere Kanten tolerieren können, Deno Desktop pilotieren — Plan B bereithalten.

Wesentliche Erkenntnisse

• Den Stack passend zum App‑Profil wählen: Agent‑Konsole (Electron), Offline‑Studio (Tauri) oder Permission‑Pilot (Deno Desktop).
• WebGPU hilft, aber große lokale Modelle verlangen weiterhin native ML‑Backends. Planen Sie Bindings und Signierungs‑Story früh.
• Ihr Updater ist Teil der Produktsicherheit. Signierte Deltas, gestaffelte Rollouts und sofortiges Rollback sind nicht verhandelbar.
• Vor der Festlegung das messen, was zählt: Installer‑Größe, Leerlauf‑RSS, t/s auf repräsentativer Hardware sowie Update‑Fehler‑/Rollback‑Raten.
• Footprint und Sicherheit schieben Richtung Tauri; Geschwindigkeit und Ökosystem ziehen Richtung Electron; Deno Desktop ist vielversprechend für permissionierte Apps, reift aber noch.