Pourquoi nous avons construit MadoHub avec Tauri plutôt qu'Electron

Quand nous avons commencé à construire MadoHub, nous avions une exigence claire : une application desktop avec une interface web capable de gérer des sessions PTY, de lire le système de fichiers et d'interagir profondément avec les processus système. Les deux vraies options étaient Electron et Tauri.

Nous avons choisi Tauri. Voici pourquoi, et ce que nous avons appris.

L'argument de la taille du binaire

L'avantage le plus cité de Tauri est la taille du binaire. Une application Electron vide fait environ 150 Mo parce qu'elle embarque un navigateur Chromium complet. Une application Tauri démarre en dessous de 5 Mo parce qu'elle utilise le webview natif du système (WebKit sur macOS, WebView2 sur Windows, WebKitGTK sur Linux).

Pour un outil de développement, la taille du binaire compte plus qu'on ne le pense. Les développeurs sont pointilleux sur ce qu'ils installent. Un téléchargement de 200 Mo pour un "outil de productivité" suscite de la méfiance. Un téléchargement de 10 Mo dit : "c'est léger et ciblé."

Mais la taille du binaire était le facteur le moins important de notre décision.

Le backend Rust

La vraie raison pour laquelle nous avons choisi Tauri, c'est le backend Rust.

MadoHub gère des sessions PTY, surveille des panneaux tmux, parse des fichiers JSONL, effectue des appels API pour le routage et gère les opérations de système de fichiers — le tout en concurrence. Ce sont des opérations système qui bénéficient de :

Sécurité mémoire sans garbage collection : la gestion des PTY implique de gérer les cycles de vie des processus, de lire des descripteurs de fichiers et de gérer des signaux. En Node.js (le backend d'Electron), un bug de gestion des processus peut fuir des descripteurs de fichiers ou laisser des processus zombies. Le modèle de propriété de Rust détecte ces bugs à la compilation.

Vraie concurrence : MadoHub surveille plusieurs processus terminaux simultanément, interroge des panneaux tmux dans des threads en arrière-plan et effectue des appels API concurrents pour le routage. Le runtime async de Rust (tokio) gère cela avec une surcharge minimale. Node.js sait faire de l'I/O asynchrone, mais les tâches CPU-bound (comme le parsing de gros fichiers JSONL) bloquent la boucle d'événements.

Gestion structurée des erreurs : les opérations système échouent de façon prévisible — les fichiers n'existent pas, les processus se terminent, les appels API expirent. Le type Result de Rust nous oblige à traiter chaque chemin d'échec. Dans notre code de routage, cela fait la différence entre un propre "session file not found, falling back to CWD resolution" et une mystérieuse erreur undefined qui fait crasher le pipeline.

Notre workspace Rust

Le backend de MadoHub est divisé en 7 crates ciblés :

Cette structure modulaire signifie que chaque crate peut être testé indépendamment, et que les temps de compilation restent raisonnables puisque les crates inchangées ne sont pas recompilées.

Le front-end

Le frontend de Tauri est un webview qui rend une application web standard. Nous utilisons React 19 + TypeScript + Tailwind CSS + Zustand pour la gestion d'état — la même pile que pour une application web.

La communication entre frontend et backend passe par le système de commandes de Tauri — essentiellement de l'IPC typé. Le frontend appelle une commande Tauri, le backend Rust l'exécute, puis le résultat revient. Pour les données en flux continu (sortie terminal, événements de routage), Tauri fournit un système d'événements.

Un avantage sous-estimé : le webview utilise le moteur de rendu natif du système, ce qui lui permet d'hériter du rendu de texte, de la physique de scroll et des fonctionnalités d'accessibilité de la plateforme. Le texte dans MadoHub a l'air natif parce qu'il est rendu nativement.

Ce à quoi nous avons renoncé

Tauri n'est pas exempt de compromis.

Incohérences de webview multiplateforme : WebKit (macOS) et WebView2 (Windows) ont des comportements de rendu différents dans certains cas limites — CSS backdrop-filter réagit différemment, certains comportements de scroll varient, et certaines Web API récentes arrivent à des dates différentes. Nous avons rencontré quelques-uns de ces cas, surtout dans les animations et les effets de flou.

Écosystème plus petit : Electron bénéficie d'un écosystème d'une décennie de plugins, d'outils de debug et de connaissances communautaires. L'écosystème de Tauri grandit vite, mais il est plus jeune. Nous avons dû construire certaines choses from scratch qui auraient été des paquets npm dans Electron.

Courbe d'apprentissage de Rust : notre équipe frontend est principalement composée de développeurs TypeScript. Écrire du Rust pour le backend a demandé un temps de montée en compétence. Le gain en vaut la peine pour le code système, mais l'investissement initial est réel.

Les performances en pratique

Pour un outil comme MadoHub — où vous pouvez avoir 5 tiles de terminal ouverts, chacun diffusant la sortie PTY, pendant que le système de routage surveille les complétions et interroge les panneaux tmux — les performances ne sont pas théoriques. Des images perdues sur le canevas, un rendu terminal lent ou des déclencheurs de routage retardés impactent directement l'utilisation.

Dans nos benchmarks, MadoHub avec 8 tiles de terminal actifs utilise environ 120 Mo de RAM. Une application Electron équivalente commencerait à 300 Mo ou plus avant même d'ouvrir un terminal, rien qu'à cause de l'overhead Chromium.

L'utilisation CPU en fonctionnement normal (terminaux actifs, routage inactif) reste sous les 5 %. Pendant le routage actif (appels API + parsing JSONL + livraison du contenu), elle monte brièvement à 15-20 % puis revient au niveau de base.

Rechoisirions-nous Tauri ?

Sans hésitation, oui, pour ce type d'application. La combinaison d'un backend Rust au niveau système et d'un frontend basé sur le web est un ajustement naturel pour des outils de développement qui ont besoin d'une intégration système profonde.

Pour une application plus simple — sans interaction système au-delà d'une I/O de fichiers basique — le choix est moins évident. La maturité d'Electron et la taille de son écosystème en font un choix pragmatique pour beaucoup de cas d'usage.

Mais pour MadoHub, où le backend gère des sessions PTY concurrentes, surveille des processus système et parse des données structurées à haut débit, Rust n'est pas seulement une optimisation de performance. C'est une garantie de correction qui nous permet de livrer avec confiance.