Choisir une pile GUI JavaScript en fonction de ce que vos utilisateurs téléchargent réellement
Découvrez pourquoi les coques de bureau et les bibliothèques de composants constituent des couches distinctes, ainsi que la manière de choisir Electron, Tauri, MUI, shadcn/ui et d’autres en fonction de leur poids à la livraison.
La recherche d’un « JavaScript GUI toolkit » donne souvent des listes où Electron est présenté à côté de Material UI comme s’ils étaient des concurrents. Ce n’est pas le cas : l’un fournit une fenêtre installable, l’autre des boutons à y placer, et la plupart des produits réels ont besoin des deux. Ce guide sépare ces deux niveaux, présente les principales options de chacun, et pose une seule question décisive pour les deux : quelle quantité de code finit sur les machines des utilisateurs, et en aviez-vous vraiment besoin ?
Deux niveaux que d’autres langages regroupent
Dans des écosystèmes tels que Qt, GTK ou WinForms, un GUI toolkit fait tout en même temps : il ouvre une fenêtre native et fournit les widgets qui s’y trouvent. JavaScript divise cette responsabilité en deux types d’outils, et c’est le mélange de ces derniers qui rend la plupart des comparaisons confuses.
- Les coques de bureau encapsulent du code web en une application installable. Ce qu’elles fournissent, c’est le cadre de l’application : une fenêtre native, une intégration dans la barre des tâches, un accès aux fichiers locaux ainsi qu’un installateur. Les widgets ne font pas partie de l’offre.
- Les bibliothèques de composants fournissent les éléments interactifs tels que des boutons, des tableaux, des sélectionneurs de dates et des dialogues. Ils s’exécutent dans un navigateur et sont indifférents au fait que ce navigateur soit intégré à une application de bureau ou qu’il s’agisse d’une simple fenêtre.
Un produit de bureau peut combiner Tauri avec MUI ; un produit web peut utiliser uniquement MUI. Choisir une coque et choisir une bibliothèque de composants sont deux décisions distinctes.
La question qui distingue réellement les options
Dans certains écosystèmes, l’octroi de licences est un facteur décisif, car une licence contraignante peut vous forcer à rendre votre produit open source. Dans le monde des interfaces graphiques en JavaScript, presque tout est sous licence MIT, si bien que la licence réduit rarement les possibilités. Ce qui le fait, c’est le poids du logiciel. Pour les shells, la différence réside entre un installateur de quelques mégaoctets et un autre de plusieurs centaines. Pour les bibliothèques de composants, il s’agit de choisir entre livrer un système de conception complet ou uniquement les quelques composants que l’on utilise réellement. Gardez cette question à l’esprit tout au long des deux parties suivantes.
Les numéros de version cités ici correspondent à npm au moment de la rédaction ; vérifiez le registre avant de vous en fier à eux. Pour une analyse plus approfondie du côté desktop, y compris les environnements de exécution plus récents, consultez notre comparaison des options desktop Electron, Tauri, Electrobun et Deno.
Shells desktop
Electron : le choix par défaut éprouvé qui inclut son propre navigateur
Electron (v44.3.0 au moment de la rédaction, licence MIT) est ajouté en tant que dépendance de développement :
npm install --save-dev electron
Celui-ci regroupe un navigateur Chromium complet ainsi qu’un environnement de exécution Node.js avec votre application. L’interface utilisateur est une page web et le backend est basé sur Node. Son principal atout réside dans sa maturité : VS Code, Slack, Discord, Figma et 1Password sont tous développés à partir de cette technologie, et les outils pour l’emballage des applications, les mises à jour automatiques, la signature du code et le rapport des pannes sont bien documentés et déjà connus de nombreuses équipes.
Le deuxième avantage est un affichage cohérent. Comme le navigateur est fourni, l’application a exactement le même aspect sous Windows, macOS et Linux, et vous testez sur une seule version de Chromium plutôt que sur trois navigateurs système différents. De plus, c’est un système entièrement basé sur JavaScript, ce qui permet à n’importe quel développeur frontend de travailler sur le processus principal.
Le inconvénient est que chaque application intègre un navigateur. Les fichiers d’installation pèsent généralement entre 80 et 200 MB, et comme chaque application Electron lance un instance distincte de Chromium, la consommation de mémoire augmente rapidement pour un utilisateur qui en exécute plusieurs. Il vous incombe également de mettre à jour ce Chromium intégré, selon votre propre calendrier de publication.
Tauri : le webview système associé à un backend en Rust
Tauri (v2.11.4 au moment de la rédaction, sous licence double Apache-2.0 ou MIT) dispose de sa propre commande de création :
npm create tauri-app@latest
Au lieu d’inclure un navigateur, Tauri utilise la vue web fournie par le système d’exploitation, et son backend est écrit en Rust plutôt qu’en Node. La différence de taille est structurelle et non progressive : selon les données communément rapportées, les fichiers compilés par Tauri pèsent environ 3 à 10 MB contre 120 à 200 MB pour Electron, avec une consommation de mémoire 50 à 75 % inférieure et un démarrage plus rapide. Comme cette différence provient de l’architecture et non d’ajustements, elle reste constante d’une version à l’autre.
Le modèle de sécurité diffère également. Dans Electron, le JavaScript du frontend peut accéder au système d’exploitation via Node à moins de le restreindre. Dans Tauri, le frontend démarre sans accès au système ; les opérations privilégiées sont des fonctions Rust que le frontend invoque par nom, et Tauri v2 a introduit un système de capacités qui contrôle quels API chaque fenêtre peut appeler. Tauri 2 cible également iOS et Android, ce que Electron ne fait pas du tout, ce qui est important pour les équipes souhaitant un seul codebase pour les postes de travail et les appareils mobiles.
Les inconvénients sont réels. Chaque WebView propre à une plateforme s’affiche légèrement différemment, ce qui signifie que vous testez désormais trois moteurs au lieu d’un seul. Tout ce qui dépasse la partie frontend nécessite du Rust. Sous Windows, Tauri repose sur WebView2, présent dans presque toutes les installations modernes, mais qui nécessite parfois un outil de démarrage. Une règle sensée : si la taille du bundle n’est pas encore source de plaintes de la part des clients, choisir Tauri uniquement pour économiser quelques mégaoctets revient à optimiser prématurément. Préférez-le lorsque des installateurs compacts, une consommation mémoire réduite, une isolation plus stricte ou une version adaptée aux appareils mobiles constituent des exigences réelles.
NW.js : l’ancien bundler Chromium
NW.js (v0.115.0 au moment de la rédaction, licence MIT) s’installe en tant que package ordinaire :
npm install nw
Il inclut également Chromium et est en fait antérieur à Electron. Sa caractéristique distinctive est que Node et le DOM partagent un même contexte, ce qui permet à une page web d’appeler directement les API de Node, sans la séparation entre processus principal et processus rendu propre à Electron. Pour certaines applications, cela simplifie la compréhension du fonctionnement. L’inconvénient est une communauté bien plus petite : moins de matériel pédagogique, moins d’outils de packaging et moins d’aide en cas de problème, tandis que la taille des fichiers restent équivalente à celle d’Electron.
Neutralino : l’enveloppe la plus petite possible
Neutralino (CLI v11.7.2 au moment de la rédaction, licence MIT) est géré par une CLI installée globalement :
npm install -g @neutralinojs/neu
Bibliothèques de composants
Tout ce qui se trouve dans cette catégorie s’exécute dans un navigateur, de sorte que chaque option fonctionne également bien tant à l’intérieur d’une interface desktop qu’à l’intérieur d’une page normale. Ici, la question du poids passe de la taille de l’installateur à la quantité de code des bibliothèques que votre fichier d’installation inclut.
MUI : couverture maximale, thème Material par défaut
MUI (v9.4.0 au moment de la rédaction, MIT) est installé avec son moteur de stylisation Emotion :
npm install @mui/material @emotion/react @emotion/styled
Parmi les bibliothèques de composants React, c’est la plus grande et la plus établie, et elle suit le système Material Design de Google. La couverture des composants est énorme, la documentation est excellente, et sa grille de données gère des volumes importants de données. Si vous avez besoin d’un composant, MUI l’a presque certainement, et quelqu’un a déjà posé la même question à son sujet.
C’est aussi une bibliothèque très volumineuse. Une installation fraîche occupe environ 19 MB dans node_modules ; ce n’est pas ce qui parvient aux utilisateurs, mais cela indique son envergure. Le bundle livré dépend du bon fonctionnement du tree-shaking, et à moins d’investir dans des thèmes personnalisés, tout ressemble au Material Design, ce que certaines équipes apprécient tandis que d’autres le trouvent contraignant.
shadcn/ui : copiez le code source plutôt que d’ajouter une dépendance
shadcn/ui (CLI v4.21.0 au moment de la rédaction, licence MIT) n’est pas un package à importer. Son CLI initialise un projet puis y copie des composants individuels :
npx shadcn@latest init
npx shadcn@latest add button dialog
Chaque composant combine des primitives Radix UI avec un stylage Tailwind, et après l’exécution du CLI, il ne reste que du code source dans votre répertoire. Si un bouton nécessite un comportement différent, vous modifiez directement ce bouton ; il n’y a pas de composant conteneur, aucune API de thématisation à gérer et aucun mainteneur à convaincre. De plus, cela garantit une taille de bundle fidèle : en ajoutant quatre composants, seuls ces quatre finissent dans le résultat de la compilation.
Le coût réel d’utilisation est la maintenance. Aucun npm update ne permettra d’améliorer vos composants ; une mise à jour signifie devoir recopier manuellement les modifications et les synchroniser. De plus, cette approche suppose l’utilisation de Tailwind, ce qui la rend peu adaptée aux projets qui ne l’emploient pas. Ce modèle fonctionne car il inverse le compromis habituel entre facilité d’utilisation et personnalisation : vous obtenez un point de départ solide ainsi qu’un contrôle total, mais en contrepartie les mises à jour deviennent votre responsabilité.
Ant Design : conçu pour des interfaces d’entreprise densément chargées
Ant Design (v6.6.3 au moment de la rédaction, licence MIT) provient d’Alibaba et s’installe en tant que seul package :
npm install antd
Il propose l’ensemble le plus complet de composants pour les interfaces professionnelles à forte charge de données : tableaux avancés, formulaires complexes, listes de transfert, sélecteurs en arbre. Pour les consoles d’administration et les outils internes, le widget dont vous avez besoin existe probablement déjà. C’est également la bibliothèque la plus lourde de cette liste, pesant environ 61 MB sur le disque après installation, soit à peu près trois fois plus que MUI ; son identité visuelle marquée est nettement plus difficile à abandonner que celle de Material.
Mantine : bons paramètres par défaut sans opinions tranchées
Mantine (v9.6.1 au moment de la rédaction, licence MIT) sépare ses composants principaux d’un package de hooks :
npm install @mantine/core @mantine/hooks
Les équipes qui trouvent MUI trop imposant et shadcn/ui trop intrusif se retrouvent souvent ici. Il dispose d’un grand ensemble de composants, de valeurs par défaut judicieuses, d’une thématique simple, d’un solide soutien pour TypeScript ainsi que d’un bon support du mode sombre sans configuration supplémentaire. Même pris séparément, le package hooks, avec des outils pour la détection de clics en dehors de l’élément, le stockage local et les requêtes médias, est utile en soi. Sa communauté est plus petite que celle de MUI ou d’Ant Design, il faut donc s’attendre à moins d’extensions tierces et à moins de solutions prêtes à l’emploi.
Radix UI et Headless UI : comportement sans mise en forme
Radix UI (v1.1.23 au moment de la rédaction) et Headless UI (v2.2.10), tous deux sous licence MIT, sont installés par primitive ou en tant que package unique respectivement :
npm install @radix-ui/react-dialog
npm install @headlessui/react
Ce sont des éléments primitifs non stylisés. Ils gèrent le comportement, la navigation au clavier, la gestion du focus et l’accessibilité, vous laissant toute liberté pour les décisions visuelles. Cette séparation est précieuse, car créer des widgets accessibles est plus complexe qu’il n’y paraît. Un vrai dialogue doit conserver le focus à l’intérieur de lui-même tant qu’il est ouvert, le restituer lorsqu’il est fermé, se fermer en appuyant sur Escape et être correctement annoncé par les technologies d’assistance ; un vrai menu déroulant nécessite une navigation au clavier avec les flèches, la possibilité de sélectionner en tapant et une disposition judicieuse près des bords de l’écran. La plupart des équipes sous-estiment ce travail et livrent des éléments légèrement défectueux.
Radix est la base sur laquelle shadcn/ui s’appuie, tandis que Headless UI est maintenu par l’équipe de Tailwind. Le coût évident est que vous devez créer tout le stylage vous-même, ce qui correspond justement à l’objectif, mais reste néanmoins un travail considérable.
PrimeReact : flexibilité pour des composants inhabituels
PrimeReact (v11.1.0 au moment de la rédaction) fait partie de la famille PrimeFaces, qui comprend également Angular, Vue et Java :
npm install primereact
Il offre une gamme extrêmement large, allant des graphiques et organigrammes aux tableaux en arborescence, outils de planification, widgets de téléchargement ainsi qu’un ensemble complet d’éléments d’entrée, dont beaucoup sont complètement absents des autres bibliothèques. Lorsque vous avez besoin de quelque chose d’original, il vaut la peine de vérifier d’abord ici.
Vérifiez vous-même sa licence avant de l’intégrer dans votre projet. Ses métadonnées npm renvoient vers un fichier de licence (“SEE LICENSE IN LICENSE.md”) au lieu d’indiquer un identifiant SPDX, et le fournisseur propose également des thèmes et modèles payants en plus de la version gratuite. La bibliothèque de base est open source, mais lisez bien les conditions réelles avant d’en utiliser pour créer un produit commercial.
Trois autres à considérer
- Chakra UI (v3.37.0, MIT) donne la priorité à l’accessibilité et stylise les composants via des props ; il se situe entre l’approche intégrée de MUI et les primitives basiques de Radix.
- daisyUI (v5.7.34, MIT) est un plugin Tailwind qui fournit des classes de composants plutôt que des composants React, ce qui signifie qu’il peut également être utilisé avec Svelte, Vue ou du markup statique.
- HeroUI (v3.2.4, MIT), successeur rebaptisé de NextUI, combine Tailwind avec React Aria.
Un guide de décision rapide
Pour l’environnement desktop :
- Un écosystème éprouvé, un rendu identique partout et une équipe utilisant uniquement JavaScript indiquent Electron.
- De petites tailles de téléchargement, une faible consommation mémoire, un modèle de sécurité plus strict ou une cible mobile indiquent Tauri.
Pour la bibliothèque de composants :
- Le besoin de presque tous les composants ainsi que d’une documentation excellente indique MUI.
- Le désir de posséder et de modifier le code dans un projet Tailwind indique shadcn/ui.
- Des écrans de données d’entreprise très chargés indiquent Ant Design.
- De bons paramètres par défaut sans opinions tranchées indiquent Mantine.
- Un système de conception personnalisé avec la accessibilité gérée à votre place indique Radix ou Headless UI.
- Un composant inhabituel et spécialisé indique PrimeReact.
Une règle prime sur toute la liste : si votre équipe connaît déjà bien l’un de ces outils, cette expertise l’emporte presque toujours sur un choix légèrement meilleur ailleurs.
Conclusion
Dans les deux catégories, les listes de fonctionnalités se sont largement rapprochées ; ces projets ont eu des années pour s’inspirer mutuellement de leurs meilleures idées. C’est en ce qui concerne la taille du fichier que les différences persistent et que les utilisateurs les ressentent. Electron contre Tauri soulève la question de la taille pour l’application dans son ensemble : intégrer un navigateur pour garantir une certaine prévisibilité, ou s’appuyer sur celui fourni par le système d’exploitation afin d’obtenir un fichier bien plus compact, vingt fois ou plus petit. Le choix entre MUI et shadcn/ui applique ce compromis au niveau des composants : compter sur un système de conception complet géré par d’autres, ou se procurer uniquement les éléments nécessaires auprès du fournisseur et les gérer soi-même. Déterminez d’abord quel camp de ce compromis votre produit choisit avant de commencer à comparer les tableaux des fonctionnalités, et la liste finale se dégagera généralement d’elle-même.