Ich habe meine Mac-Electron-App in Rust neu geschrieben

• Der Entwickler hat die bestehende Mac-App Desktop Docs, die ursprünglich mit Electron gebaut wurde, in Rust neu geschrieben – und das war letztlich die richtige Entscheidung
• Die erste mit Electron entwickelte App war mit 1 GB sehr groß und hatte Performance-Probleme, wodurch sie häufig abstürzte
  • Besonders problematisch war der Leistungsabfall bei der Verarbeitung großer Bild- und Videomengen
• Nach dem Rebuild mit Rust + Tauri wurde die App 83 % kleiner, die Indexierung mehr als dreimal schneller und auch die Stabilität verbessert
  • App-Größe: 1 GB → 172 MB (83 % kleiner)
  • Installationsdatei: 232 MB → 69.5 MB (70 % kleiner)
  • Video-Indexierung: bei einem 38-minütigen Video 10~14 Minuten → 3 Minuten
  • Deutlich stabilerer Betrieb als die instabile Electron-App
• Rebuild-Prozess und Entscheidungen
  • Bei der Electron-App belegte Chromium selbst im Hintergrund mehr als 200 MB RAM, und sogar Videotelefonie konnte Abstürze auslösen
  • In der neuen App werden CLIP-Embeddings und der Redis-Vektor-Store weiterhin verwendet
  • Allerdings wurde in Rust die gesamte Pipeline für Bild-/Videoverarbeitung und Datei-I/O neu geschrieben
  • Auch die UI wurde nicht portiert, sondern von Grund auf neu entwickelt, was am Ende zu einer saubereren und einfacheren Oberfläche führte
• Technische Schwierigkeiten
  • Rust hat eine steile Lernkurve, und die Tauri-Community ist noch weniger ausgereift als die von Electron
  • Beim Bundling von Redis in die App gab es Probleme mit Berechtigungen und Distribution
  • Trotzdem wurden gegenüber Electron Kontrolle und Performance insgesamt verbessert
• Fazit
  • Vollständige Funktionsgleichheit ist noch nicht erreicht, aber die Kernfunktionen laufen deutlich schneller und stabiler
  • „Code, der zwar funktioniert, aber falsch gebaut ist, sollte man mutig verwerfen“

[choyunsung79]

Electron enthält Chromium, während Tauri die auf dem Betriebssystem installierte Engine verwendet – darin liegt der Unterschied.

Tauri (OS WebView)** ist vorteilhaft, wenn leichtgewichtige Auslieferung und schnelle Performance wichtig sind,
aber bei Diensten, bei denen Sicherheit, Zuverlässigkeit und Kontrolle über Funktionen entscheidend sind, ist der Electron-Ansatz (mit eingebettetem Chromium) besser geeignet.

Was die Probleme im Code angeht, kenne ich die Details nicht genau, aber ich denke, dass die Eigenschaften der Plattform stark hineinspielen.

[bus710]

Wenn es um Flutter geht, ist auch rinf ziemlich gut.

[aer0700]

Ich habe zwar schon Electron verwendet, aber noch nie mit Tauri gearbeitet. Ich sollte es wohl irgendwann mal ausprobieren.

[GN⁺]

Hacker-News-Kommentare

• Ich entwickle gerade eine Desktop-App mit Rust und egui, und da sowohl Rust als auch Desktop-Entwicklung Neuland für mich sind, fühlt es sich schwierig an, so viele Konzepte auf einmal zu lernen. Mein Bereich sind Analyse-Tools für den Maschinenbau, daher braucht das Backend hohe Performance und das Frontend Datenvisualisierung. Mich würde interessieren, ob es bei der Nutzung von Tauri nicht schwierig war, mehrere Stacks wie Rust, JS und HTML gleichzeitig zu verwalten.

• Ich habe kürzlich ein Projekt von Tauri zu Electron migriert. Die Unterschiede beim Rendering der Webviews auf verschiedenen Plattformen waren ein ziemlicher Schmerzpunkt. Mich würde interessieren, ob du jemals plattformübergreifende UI-Bugs erlebt hast. Die UI-Anforderungen sind einfach, die Berechnungen komplex, daher denke ich, dass sich die QA-Kosten trotz allem lohnen würden. Ich frage mich, ob meine Erfahrung ungewöhnlich war oder ob Rendering-Unterschiede tatsächlich ein häufiges Problem sind. Und mich würde interessieren, ob du Tauri 1.0 oder 2.0 verwendet hast. 2.0 wurde offiziell veröffentlicht, während ich gerade von v1 umgestellt habe; die Migration war ein Albtraum und die Dokumentation war wirklich sehr dürftig. Ich frage mich, ob sie inzwischen besser geworden ist.

  • Wir verwenden bei kreya.app eine selbst implementierte System-Webview-Lösung (also nicht Tauri), und in der Praxis sind Plattformunterschiede kaum ein Problem. Das meiste lässt sich mit Polyfills lösen, und wir führen unter Linux End-to-End-Automatisierungstests aus, die die meisten Probleme finden. Am schwierigsten ist es, herauszufinden, wie veraltet die Webview-Versionen der Nutzer sind. Unter Linux und macOS ist das ein großes Problem, unter Windows ist es dank WebView2 deutlich besser.
  • Tatsächlich haben wir mit der Tauri-Version noch keine plattformübergreifende Distribution ausgeliefert, wir werden das also noch sehen. Zum Glück sind die UI-Anforderungen einfach. Mich würde interessieren, welche Rendering-Unterschiede du mit Tauri erlebt hast. Auf welcher Plattform lief die App am besten oder zeigte die meisten Probleme? Wir wollen ebenfalls Windows-Support. In der Electron-Version gab es Probleme beim Ausführen gebündelter Binärdateien auf Intel-Macs, und das war so lästig, dass wir beschlossen haben, uns beim Rebuild mit Tauri zunächst auf eine Plattform zu konzentrieren: Mac mit Apple-Chip. Wir sind mit Tauri 1.4 unterwegs und hatten bisher keine Probleme. Die Migrationsdokumentation für 2.0 werde ich mir ebenfalls noch ansehen.
  • Zur Frage, ob wir plattformübergreifende UI-Bugs erlebt haben: natürlich nicht, da wir bisher nur Mac unterstützen. Wenn wir auch Windows und Linux unterstützt hätten, wäre dieser Beitrag vermutlich gar nicht erst entstanden. Plattformübergreifende UI ist wirklich schwierig, und noch schwieriger wird es, wenn man dieselbe UI und denselben Funktionsumfang beibehalten und zusätzlich eine Online-Version im Blick haben will. Deshalb sind viele von nativen Ansätzen zu Qt und Web-Stacks gewechselt. Meiner Erfahrung nach arbeite ich in einem Unternehmen, das plattformübergreifende Desktop-Apps mit Millionen von Nutzern entwickelt, und ich kann mir kaum vorstellen, das anders zu machen.
  • Als ich vor etwa sechs Monaten Tauri V2 verwendet habe, war die Dokumentation komplett chaotisch. Das Projekt selbst ist vielversprechend, aber mangels Referenzen war es wirklich mühsam, etwas sauber umzusetzen.
  • Kürzlich hat Tauri dazu Folgendes angekündigt: Dieses Jahr sollen neue Technologien wie CEF- und SERVO-basierte Webviews vorgestellt werden; das wurde auf Discord bekanntgegeben.

• Ich bin einen ähnlichen Weg gegangen. Ich habe einen einfachen Webcam-Viewer gebaut, optimiert für USB-Mikroskope, weil es nichts Vernünftiges gab und ich ihn deshalb selbst gemacht habe. Fast alle Funktionen habe ich im Renderer implementiert. Als ich dann die Einreichung im App Store vorbereitet habe, fragte ich mich, ob ein 500-MB-Webcam-Viewer wirklich Sinn ergibt, also habe ich ihn auf Tauri V2 portiert und die Größe auf fast 15 MB reduziert.

  • Mich würden die Unterschiede zwischen Tauri und Electron interessieren. So wie ich es verstehe, nutzen beide einen Browser zum Rendern, aber Electron bringt den kompletten eigenen Browser mit, während Tauri den bereits auf dem System vorhandenen Browser verwendet.
  • Wirklich beeindruckend. Mich würde interessieren, um welches Produkt es sich handelt. Wir bereiten diese Woche ebenfalls die Einreichung im App Store vor.

• Ich mag die Idee dieser App wirklich sehr. Andere Apps in diesem Bereich sind oft extrem träge und unhandlich, daher interessiert mich der Rewrite sehr. Ich bin allerdings Fotograf und ein großer Teil meiner Medien liegt im RAW-Format vor; ich bin mir nicht sicher, ob das unterstützt wird (oder vielleicht eher nicht, wenn RAW bei „allen wichtigen Bild- und Videoformaten“ nicht erwähnt wird). Mich würde interessieren, ob es offizielle Dokumentation, ein Nutzerforum oder andere Kanäle gibt, in denen man solche Details prüfen kann.

• Ich bin weder Mac-Nutzer noch denkt unser Team über einen Rewrite in Rust nach, aber ich freue mich sehr über diesen Beitrag. Genau diese Art von „Show HN“-Post wünsche ich mir: in diesem Umfang, mit einer Zusammenfassung der technischen Trade-offs, die man braucht, um reale Probleme zu lösen. Danke.

  • Ich freue mich, meine Erfahrungen teilen zu können. Es war keine leichte Entscheidung, etwas neu zu bauen, das bereits funktionierte, aber im Ergebnis bin ich sehr zufrieden.

• Es wäre wirklich großartig, aktuelles Benchmark-Material zu haben, das Tauri, Flutter, Electron, React Native und andere moderne plattformübergreifende Frameworks vergleicht. Wichtige Kennzahlen wären Paketgröße, Speicherverbrauch (RAM), Startzeit, CPU-Auslastung unter Last und belegter Speicherplatz. Gerade bei Frameworks wie Tauri, bei denen Rendering und Performance je nach Webview-Version variieren, wäre auch eine Kompatibilitätsmatrix pro Plattform (WebView2, WKWebView usw.) hilfreich. Wenn man diese Unterschiede visuell in Tabellenform zusammenfassen würde, könnten Entwickler deutlich bessere Entscheidungen treffen.

  • Es gibt einen aktuellen Vergleich von vor zwei Wochen. Zu finden unter web-to-desktop-framework-comparison. Electron ist bei der Laufzeit-Performance ziemlich konkurrenzfähig. Ich denke, man sollte sich mehr um den Speicherverbrauch als um den Festplattenspeicher kümmern.
    • Windows (x64) Speicherverbrauch (einzelnes Fenster, Release-Build):
    1. Electron: ca. 93MB
    2. NodeGui: ca. 116MB
    3. NW.JS: ca. 131MB
    4. Tauri: ca. 154MB
    5. Wails: ca. 163MB
    6. Neutralino: ca. 282MB
    • Mac (arm64):
    1. NodeGui: ca. 84MB
    2. Wails: ca. 85MB
    3. Tauri: ca. 86MB
    4. Neutralino: ca. 109MB
    5. Electron: ca. 121MB
    6. NW.JS: ca. 189MB
    • Linux (x64):
    1. Tauri: ca. 16MB
    2. Electron: ca. 70MB
    3. Wails: ca. 86MB
    4. NodeGui: ca. 109MB
    5. NW.JS: ca. 166MB
    6. Neutralino: ca. 402MB
  • Ich würde gern mehr solche Vergleichsmaterialien sehen.

• In einem früheren Unternehmen habe ich eine Desktop-Electron-App für Windows und Mac gewartet. Die App war viel zu schwergewichtig, und Updates mit Squirrel waren mühsam.
  Letztlich haben wir die GUI als Web-SPA (auf Basis von Inferno) beibehalten, aber Dinge wie das Laden der Webview durch jeweils kleine native Apps (C# und Swift) ersetzt. Dadurch sanken Downloadgröße und Speicherverbrauch um etwa 90 %, und wir sind auf Verteilung und Updates über die jeweiligen App Stores der Plattformen umgestiegen. Ich halte das für die beste Entscheidung.

  • Ich glaube, das ist fast das erste Mal, dass ich jemanden Verteilung/Updates über native App Stores loben höre.
    Ich mache mir Sorgen über Freigabezeiten und die Unwägbarkeiten von Updates; mich würde interessieren, was sich durch den Wechsel von Squirrel zu nativen Lösungen verbessert hat.
  • Mich würde interessieren, wie lange die Umstellung gedauert hat.

• Wenn die endgültige App für den Mac ist, würde mich wirklich interessieren, warum du Rust/Tauri statt Swift/SwiftUI gewählt hast.

  • Danke fürs Nachfragen. Das Ziel von Desktop Docs ist Plattformübergreifung. Es gab viele Anfragen nach Windows-Support, deshalb fiel die Wahl auf Rust, um künftig auf eine Windows-Version vorbereitet zu sein.
  • Ich wollte dieselbe Frage stellen. Ich finde, Swift ist eine ziemlich gute Sprache und hat viele ähnliche Vorteile wie Rust. Mich interessieren auch die Aussagen zur CLIP-Integration, und ich fand die Portierungsstory sehr gut.
  • Das frage ich mich auch. Ich möchte bald eine Desktop-App bauen, habe lange Swift genutzt und kenne Rust nur ein wenig. Tauri wirkt sehr attraktiv. Electron-Apps starten selbst auf schnellen PCs viel zu langsam. Danke für die Einblicke.

• Mich würde interessieren, was den Ausschlag gegeben hat, Tauri statt egui zu wählen. Lag es an den Erfahrungen mit Electron? Ich möchte ebenfalls eine Python-Qt-App nach Rust portieren, habe aber Sorge, dass die GUI-Bibliotheken in Rust noch nicht so ausgereift sind wie Qt und ich am Ende festhänge.

  • Mich würde grundsätzlich interessieren, was überhaupt der Auslöser dafür war, über eine Portierung nachzudenken.

• Wenn man auf der Haupt-Landingpage den Button „Try“ sieht, erwartet man als Nutzer so etwas wie eine Testversion, tatsächlich landet man aber direkt beim Kauf. Eine einwöchige Testversion, selbst kurz, wäre schön.
  Ich bin Fan der dauerhaften Backup-Lizenzpolitik. 99 $ sind eine ziemlich hohe Einstiegshürde, aber wenn ihr auf Creator/Studios zielt, ist das nachvollziehbar; für normale Verbraucher wären 20–25 $ aus meiner Sicht passend.
  Im Text wird die Performance stark betont, auf der Landingpage wird sie aber überhaupt nicht erwähnt. Wie bei dem 38-minütigen Video wären Informationen zu Benchmarks, Parallelverarbeitung oder VRAM-Anforderungen ebenfalls wichtig. Mich würde interessieren, wie sich das Ganze in der Praxis bei Hunderten bis Tausenden Stunden Medienmaterial verhält.
  Es ist erstaunlich, dass ein Vorgang, der in Electron 10–14 Minuten dauerte, in Tauri auf 3 Minuten reduziert wurde. Wenn Electron nur CLIP und ffmpeg orchestriert hat, frage ich mich, woher dieser Overhead kommt.
  Ich selbst habe früher mit Electron ein Medien-Suchtool auf Basis von Video-Transkription gebaut und hatte nicht viele Performance-Probleme.
  Normalerweise wählt man Electron oder Tauri wegen der Plattformübergreifung; deshalb frage ich mich, warum es von vornherein nur für den Mac gedacht ist (zumal bei großvolumiger Medienverarbeitung ja auch NVIDIA genutzt werden könnte).
  Ich habe selbst vor Kurzem nach zehn Jahren wieder Swift verwendet und zwischen Tauri und Swift geschwankt, mich bei einem neuen Projekt aber für Swift entschieden; im Vergleich zu etwa 2014 hat es sich enorm weiterentwickelt und war fast durchgehend angenehm.
  Wenn der Abschnitt zu aktiven Nutzern stimmt, scheint ihr bereits einen gewissen Erfolg zu haben; mich würde interessieren, ob ihr vorher schon ein Netzwerk oder Publikum in der Studio-/Creator-Branche hattet. Auch zum Marketing würde ich gern mehr hören.

  • Danke für das Feedback. Aus Infrastrukturgründen konnten wir eine Testversion bisher noch nicht umsetzen, planen aber, sie künftig in Betracht zu ziehen.
    Du hast erwähnt, dass du selbst ein ähnliches Tool gebaut hast; mich würde interessieren, warum du es nicht veröffentlicht hast.
    Windows- und Linux-Versionen sollen, falls die Nachfrage da ist, in den nächsten Monaten ebenfalls erscheinen.
    Nutzer haben wir über HN, einen Launch auf Reddit und etwas Werbung auf LinkedIn gewonnen. Das meiste kam über Mundpropaganda.
    Zur Performance von Electron bei der Videoverarbeitung könnte ich noch viel mehr sagen. Ich bin selbst kein Electron-Experte, daher könnte es auch sein, dass wir Worker nicht richtig genutzt haben und dadurch Engpässe entstanden sind.
    Mit dem Wechsel zu Rust haben wir außerdem Scene Detection eingeführt, um die Zahl der zu indexierenden Frames zu reduzieren, was die Verarbeitungslast deutlich gesenkt hat. Außerdem haben wir GPU-Beschleunigungsoptionen von ffmpeg hinzugefügt, was die Performance spürbar verbessert hat. Die Erzeugung von Bild-Embeddings wurde ebenfalls per Batch-Verarbeitung optimiert. Wenn man es aber zu weit treibt, kann die Modellinstanz abstürzen.

[secret3056]

In der auf HN verlinkten Leistungsvergleichstabelle scheint Electron in den meisten Fällen besser als Tauri zu sein....

[majorika]

Ich habe deutlich den Eindruck, dass der Leistungsvergleich in den Kommentaren Werte aus dem Repository herauspickt, die Electron günstig sind. Die Zahlen weichen zwar leicht ab, aber der ähnlichste Vergleichspunkt ist der Teil, in dem die „Differenz zwischen freiem Speicher vor dem Start und freiem Speicher nach dem Start“ verglichen wird. Direkt darüber ist jedoch beim Punkt zur Gesamtsumme des Speichers von Hauptprozess und Kindprozessen während der Ausführung für Electron ein Wert von 258 M verzeichnet, sodass der angegebene Wert von 91 MB für die Veränderung des Speicherverbrauchs vor und nach dem Start nur schwer nachzuvollziehen ist. Auch in einer Antwort auf HN wird erwähnt, dass die mit Tauri erstellte App mehr als 7 Sekunden zum Starten gebraucht habe, was ebenfalls darauf hindeutet, dass die Messwerte im Repository nur schwer verlässlich sind.

[wfedev]

Hm, die meisten Probleme scheinen eher mit der WebView-Engine sowie dem Betriebssystem bzw. den Treibern zusammenzuhängen als mit den Unterschieden zwischen Electron und Tauri.