J’ai réécrit mon app Mac Electron en Rust

• Le développeur a réécrit Desktop Docs, une application Mac initialement développée avec Electron, en Rust, et au final c’était le bon choix
• La première version de l’application, construite avec Electron, pesait 1 Go et plantait souvent à cause de problèmes de performances
  • En particulier, elle souffrait de fortes baisses de performances lors du traitement de grandes images et vidéos
• Après une refonte en Rust + Tauri, la taille de l’application a diminué de 83 %, la vitesse d’indexation a été améliorée de plus de 3 fois, et la stabilité s’est aussi améliorée
  • Taille de l’application : 1 Go → 172 Mo (83 % de réduction)
  • Fichier d’installation : 232 Mo → 69,5 Mo (70 % de réduction)
  • Indexation vidéo : pour une vidéo de 38 minutes, 10~14 minutes → 3 minutes
  • Une exécution bien plus stable que l’application Electron, qui était instable
• Le processus de refonte et les choix techniques
  • Même en arrière-plan, l’application Electron voyait Chromium consommer à lui seul plus de 200 Mo de mémoire, et un simple appel vidéo pouvait même provoquer un crash
  • Dans la nouvelle application, les embeddings CLIP et le vector store Redis ont été conservés
  • En revanche, tout le pipeline de traitement d’images/vidéos et d’E/S de fichiers a été entièrement réécrit en Rust
  • L’interface aussi a été réécrite de zéro au lieu de simplement porter le code existant, ce qui a permis d’obtenir une interface plus propre et plus simple
• Difficultés techniques
  • La courbe d’apprentissage de Rust est élevée, et la communauté Tauri n’est pas encore aussi mature que celle d’Electron
  • Lors de l’intégration de Redis dans l’application, il y a eu des problèmes de permissions et de distribution
  • Malgré cela, le niveau global de contrôle et les performances sont meilleurs qu’avec Electron
• Conclusion
  • L’équivalence fonctionnelle complète n’est pas encore atteinte, mais les fonctionnalités clés sont bien plus rapides et stables
  • « Il faut savoir jeter sans hésiter un code qui fonctionne, mais qui a été mal conçu »

[choyunsung79]

Electron intègre Chromium, tandis que Tauri utilise le moteur installé sur l’OS, d’où la différence.

Tauri (OS WebView)** est avantageux lorsqu’un déploiement léger et de bonnes performances sont nécessaires,
mais pour les services où la sécurité, la fiabilité et le contrôle des fonctionnalités sont importants, l’approche Electron (Chromium intégré) est plus adaptée.

Je ne connais pas bien les problèmes du code, mais je pense que les caractéristiques de la plateforme se reflètent beaucoup.

[bus710]

Si c’est Flutter, rinf est aussi vraiment très bien.

[aer0700]

J’ai déjà utilisé Electron, mais je n’ai jamais touché à Tauri, donc il faudrait que je l’essaie au moins une fois.

[GN⁺]

Commentaires Hacker News

• Je crée une application desktop avec Rust et egui, et comme c’est ma première fois à la fois avec Rust et le développement desktop, j’ai du mal à assimiler autant de concepts d’un coup. Mon domaine, ce sont les outils d’analyse en génie mécanique, donc le backend doit offrir de hautes performances et le frontend doit répondre à des besoins de visualisation de données. Je me demande si gérer plusieurs stacks en même temps — Rust, JS, HTML, etc. — n’a pas été difficile avec Tauri.

• J’ai récemment eu l’expérience de migrer un projet de Tauri vers Electron. Les différences de rendu entre les webviews utilisées selon les plateformes m’ont donné du fil à retordre. Je me demande si vous avez déjà rencontré des bugs d’UI en cross-platform. Les exigences UI sont simples et les calculs sont complexes, donc même s’il faut payer un coût QA, je pense que ça en vaut la peine. Je me demande si mon expérience était atypique, ou si les différences de rendu sont vraiment un problème courant. Et je me demande aussi si vous utilisiez Tauri 1.0 ou 2.0. J’ai migré quand la 2.0 est sortie officiellement alors que j’étais encore en train de modifier la v1, et la migration a été un cauchemar, avec en plus une documentation vraiment insuffisante. Je me demande si la documentation s’est améliorée depuis.

  • Chez kreya.app, nous utilisons directement la webview système (donc pas Tauri) et, en pratique, les différences entre plateformes posent très peu de problèmes. Les polyfills règlent l’essentiel, et nous exécutons des tests automatisés end-to-end sous Linux, ce qui permet de détecter la plupart des soucis. Le plus difficile, c’est de savoir à quel point la version de la webview chez l’utilisateur est en retard. C’est un gros sujet sur Linux et Mac, alors que Windows est nettement mieux loti grâce à WebView2.
  • En fait, nous n’avons pas encore déployé la version Tauri en cross-platform, donc nous le vérifierons plus tard. Heureusement, les exigences UI sont simples. Je me demande quels types de différences de rendu vous avez rencontrés avec Tauri. Quelle plateforme fonctionnait le mieux, ou posait le plus de problèmes, dans votre application ? Nous voulons aussi prendre en charge Windows. Dans la version Electron, nous avions des problèmes pour exécuter les binaires embarqués sur les Mac à puce Intel, et c’était tellement pénible que, pour la reconstruction avec Tauri, nous avons décidé de nous concentrer d’abord sur une seule plateforme : Mac (Apple chip). Nous sommes partis sur Tauri 1.4 et, pour l’instant, aucun problème. Je regarderai aussi plus tard la documentation de migration vers la 2.0.
  • Pour répondre à la question sur les bugs d’UI cross-platform : évidemment, ce n’est pas vraiment applicable puisque nous ne prenons en charge que Mac pour l’instant. Si nous avions essayé de supporter aussi Windows et Linux, je pense que cet article n’aurait même pas pu exister. L’UI cross-platform est vraiment difficile, et c’est encore pire si l’on veut garder la même interface et le même ensemble de fonctionnalités tout en pensant aussi à une version en ligne. C’est pour cela que tout le monde est passé du natif à Qt, puis aux stacks web. D’après mon expérience — je travaille dans une entreprise qui développe une application desktop cross-platform avec plusieurs millions d’utilisateurs — je n’arrive pas à imaginer une autre approche.
  • Quand j’ai utilisé Tauri V2 il y a environ 6 mois, la documentation était totalement désastreuse. Le projet lui-même est prometteur, mais comme il n’y avait presque rien à consulter, c’était vraiment pénible d’implémenter correctement quoi que ce soit.
  • Tauri a récemment annoncé ce genre de nouveauté : ils ont indiqué sur Discord qu’ils comptaient présenter cette année de nouvelles technologies, notamment des webviews basées sur CEF et SERVO.

• J’ai suivi un chemin assez similaire. J’ai créé un petit visualiseur de webcam optimisé pour un microscope USB, parce qu’il n’existait rien de satisfaisant et que j’ai donc fini par le faire moi-même. J’ai implémenté presque toutes les fonctionnalités dans le renderer. En préparant la soumission à l’App Store, je me suis demandé si un visualiseur de webcam de 500 Mo avait vraiment du sens, alors je l’ai porté vers Tauri V2 et j’ai réduit la taille à presque 15 Mo.

  • Je me demande quelle est exactement la différence entre Tauri et Electron. Si j’ai bien compris, les deux utilisent un navigateur pour le rendu, mais Electron embarque l’intégralité de son propre navigateur, alors que Tauri s’appuie sur celui déjà présent sur le système.
  • Je trouve ça vraiment impressionnant. Je me demande de quel produit il s’agit. Nous aussi, nous préparons une soumission à l’App Store cette semaine.

• J’aime beaucoup l’idée de cette application. Les autres applications de ce domaine sont souvent trop lentes et peu pratiques, donc cette réécriture m’intéresse beaucoup. En revanche, comme je suis photographe, une grande partie de mes médias est au format RAW, et je ne suis pas sûr que ce soit pris en charge (ou alors, comme RAW ne figure pas dans « tous les principaux formats image et vidéo », ce n’est peut-être pas le cas). Je me demande s’il existe une documentation officielle, un forum utilisateur ou d’autres canaux où l’on pourrait vérifier ce genre de détail.

• Je ne suis pas utilisateur Mac, et notre équipe n’envisage pas non plus de réécriture en Rust, mais je suis très heureux de voir ce billet. C’est exactement le type de longueur que j’attends d’un « Show HN » : quelque chose qui résume les compromis techniques nécessaires pour résoudre un vrai problème. Merci.

  • Ravi de pouvoir partager cette expérience. La décision de reconstruire quelque chose qui fonctionnait déjà n’a pas été facile, mais au final j’en suis satisfait.

• Ce serait vraiment bien d’avoir un benchmark récent comparant Tauri, Flutter, Electron, React Native et d’autres frameworks cross-platform modernes. Les principaux indicateurs seraient la taille du bundle, l’utilisation mémoire (RAM), le temps de démarrage, l’utilisation CPU en charge, l’espace disque occupé, etc. Surtout pour des frameworks comme Tauri, où le rendu et les performances peuvent varier selon la version de la webview, il serait utile d’ajouter aussi une matrice de compatibilité par plateforme (WebView2, WKWebView, etc.). Si l’on organisait visuellement ces différences dans un tableau, les développeurs pourraient faire de bien meilleurs choix.

  • Il existe un comparatif récent publié il y a deux semaines. On peut le consulter sur web-to-desktop-framework-comparison. Electron reste assez compétitif en performance d’exécution. Je pense qu’il faut davantage se soucier de l’utilisation mémoire que de l’espace disque.
    • Utilisation mémoire sous Windows (x64) (fenêtre unique, build release) :
    1. Electron : environ 93 Mo
    2. NodeGui : environ 116 Mo
    3. NW.JS : environ 131 Mo
    4. Tauri : environ 154 Mo
    5. Wails : environ 163 Mo
    6. Neutralino : environ 282 Mo
    • Mac (arm64) :
    1. NodeGui : environ 84 Mo
    2. Wails : environ 85 Mo
    3. Tauri : environ 86 Mo
    4. Neutralino : environ 109 Mo
    5. Electron : environ 121 Mo
    6. NW.JS : environ 189 Mo
    • Linux (x64) :
    1. Tauri : environ 16 Mo
    2. Electron : environ 70 Mo
    3. Wails : environ 86 Mo
    4. NodeGui : environ 109 Mo
    5. NW.JS : environ 166 Mo
    6. Neutralino : environ 402 Mo
  • J’aimerais voir davantage de comparatifs de ce genre.

• Dans mon ancienne entreprise, j’ai maintenu une application desktop Electron pour Windows et Mac. L’application était beaucoup trop lourde, et les mises à jour via Squirrel étaient un calvaire.
  Nous avons fini par conserver l’interface graphique sous forme de SPA web (basée sur Inferno), tout en remplaçant le chargement de la webview et autres éléments par de petites applications natives distinctes (C# et Swift). Résultat : le volume de téléchargement et l’utilisation mémoire ont baissé d’environ 90 %, et nous sommes passés à une distribution et des mises à jour via les App Stores de chaque plateforme. Franchement, c’était la meilleure décision.

  • C’est presque la première fois que je vois quelqu’un faire l’éloge de la distribution et des mises à jour via les App Stores natifs.
    Les délais d’approbation et leur imprévisibilité m’inquiètent ; je me demande ce qui s’est amélioré pour vous en passant de Squirrel au natif.
  • Je me demande combien de temps la transition a pris.

• Si l’application finale est sur Mac, je me demande vraiment pourquoi avoir choisi Rust/Tauri plutôt que Swift/SwiftUI.

  • Merci d’avoir vérifié. L’objectif de Desktop Docs est le cross-platform. Comme il y avait beaucoup de demandes de support Windows, nous avons choisi Rust en anticipant une future version Windows.
  • J’allais poser exactement la même question. Swift est un langage plutôt agréable, et je pense qu’il offre beaucoup d’avantages similaires à Rust. J’aimerais aussi en savoir plus sur l’intégration de CLIP, et j’ai beaucoup apprécié le récit du portage.
  • Je me pose aussi la question. Je vais bientôt créer une application desktop ; cela fait longtemps que j’utilise Swift et je ne connais Rust qu’un tout petit peu. Tauri semble très séduisant. Les applications Electron démarrent toujours trop lentement, même sur des PC rapides. Merci pour ces éclairages.

• Je me demande ce qui vous a poussé à choisir Tauri plutôt que egui. Est-ce lié à votre expérience avec Electron ? J’essaie moi aussi de porter une application Python/Qt vers Rust, mais j’ai peur de me retrouver bloqué en cours de route parce que les bibliothèques GUI de Rust ne sont pas encore aussi complètes que Qt.

  • Plus fondamentalement, je me demande ce qui vous a amené à envisager le portage au départ.

• En voyant le bouton "Try" sur la page d’accueil principale, on a l’impression qu’il existe une version d’essai, alors qu’en réalité cela mène directement à l’achat. Une période d’essai d’une semaine, même courte, serait appréciable.
  Je suis fan de la politique de licence de secours à vie. 99 $ constitue une barrière à l’entrée assez élevée, mais cela se tient si vous ciblez les créateurs/studios ; pour le grand public, 20 à 25 $ me sembleraient plus adaptés.
  L’article met l’accent sur les performances, mais la page d’accueil n’en parle pas du tout. Comme pour la vidéo de 38 minutes, des informations sur les benchmarks, le travail en parallèle ou les besoins en VRAM seraient importantes. Je me demande ce qu’il en est en pratique quand on traite des centaines ou des milliers d’heures de médias.
  Je trouve étonnant qu’une tâche prenant 10 à 14 minutes sous Electron tombe à 3 minutes avec Tauri. Si Electron ne faisait qu’orchestrer CLIP et ffmpeg, je me demande d’où pouvait venir une telle surcharge.
  J’ai moi-même créé autrefois avec Electron un outil de recherche média basé sur la transcription vidéo, et je n’avais pas eu de gros problèmes de performances.
  En général, on choisit Electron ou Tauri pour le cross-platform ; je me demande donc pourquoi être parti dès le départ sur du Mac-only (surtout pour du traitement média lourd, où l’usage de NVIDIA pourrait aussi être intéressant).
  J’ai moi aussi réutilisé Swift récemment, pour la première fois depuis dix ans, et après avoir hésité avec Tauri pour un nouveau projet, j’ai choisi Swift ; comparé à 2014, le langage a énormément progressé et l’expérience était presque agréable.
  Si la section sur les utilisateurs actifs est exacte, on dirait que vous avez déjà rencontré un certain succès ; je me demande si vous aviez déjà un réseau ou une audience dans le secteur des studios/créateurs. J’aimerais aussi en savoir plus sur la partie marketing.

  • Merci pour le retour. Côté infrastructure, nous n’avons pas encore pu implémenter de version d’essai, mais nous envisageons de le faire à l’avenir.
    Vous avez dit avoir créé un outil similaire vous-même ; je me demande pourquoi vous ne l’avez pas lancé.
    Des versions Windows et Linux sont également prévues dans les prochains mois s’il y a de la demande.
    Nous avons acquis nos utilisateurs via HN, un lancement sur Reddit et un peu de promotion sur LinkedIn. La plupart viennent du bouche-à-oreille.
    Sur les performances d’Electron dans le traitement vidéo, il y aurait beaucoup à dire si l’on entrait dans le détail. Je ne suis pas un expert d’Electron non plus ; il est possible que notre goulot d’étranglement vienne du fait que nous n’utilisions pas correctement les workers.
    En passant à Rust, nous avons aussi introduit la détection de scènes (scene detection), afin de réduire le nombre d’images à indexer, ce qui a fortement diminué la charge de traitement. Nous avons également ajouté les options d’accélération GPU de ffmpeg, ce qui a pas mal amélioré les performances. La génération d’embeddings d’image a aussi été optimisée par traitement par lots. En revanche, si on pousse trop loin, l’instance du modèle peut planter.

[secret3056]

Dans le tableau comparatif des performances lié sur HN, Electron semble être meilleur que Tauri dans la plupart des cas....

[majorika]

J’ai l’impression que la comparaison des performances dans les commentaires reprend, de façon assez sélective, les valeurs du dépôt qui favorisent Electron. Les chiffres diffèrent légèrement, mais la mesure la plus comparable semble être celle qui confronte la « différence de mémoire disponible avant l’exécution et après l’exécution ». Or, dans la section juste au-dessus, le total de la mémoire du processus principal et des processus enfants pendant l’exécution est indiqué à 258M pour Electron, donc il est difficile d’admettre que la variation d’utilisation mémoire entre avant et après exécution ne soit que de 91 MB. Dans une réponse sur HN aussi, quelqu’un souligne que le temps de démarrage d’une application construite avec Tauri y dépasse 7 secondes, ce qui remet également en cause la fiabilité des mesures du dépôt.

[wfedev]

Hum, j’ai l’impression que la plupart des problèmes viennent davantage du moteur WebView et de soucis liés à l’OS/aux pilotes que des différences entre Electron et Tauri.