Tout le monde déteste Electron : pourquoi refuse-t-il de disparaître ?

Le problème central d’Electron est simple : chaque application apporte son propre navigateur. Il regroupe des technologies web (HTML, CSS, JavaScript) avec Node.js.js pour l’interaction avec le système, puis enveloppe le tout dans un runtime Chromium dédié. Cette architecture signifie que chaque application Electron est un environnement web autonome, indépendant du navigateur natif du système d’exploitation.

Cette conception pèse lourdement sur les ressources système. Prenons Claude sur macOS : l’Electron Framework à lui seul occupe 286 MB des 618 MB de l’application. Sur un Mac, 22 applications Electron représentaient collectivement 6,5 GB de copies dupliquées de Chromium. Chaque instance de Chromium exige également de la mémoire : Claude, simplement ouvert, utilisait environ 600 MB de RAM répartis sur 11 processus.

Ces chiffres, tirés d’une vidéo de Better Stack, illustrent la charge. Il est essentiel de noter qu’il s’agit d’exemples précis, et non de références universelles. La taille finale et l’empreinte mémoire d’une application varient considérablement selon les outils intégrés, les bibliothèques spécifiques et la charge de travail active, mais l’inefficacité sous-jacente des instances Chromium isolées demeure.

Les détracteurs d’Electron présentent souvent le développement natif comme la contrepartie évidente, mais cette voie implique de multiplier les efforts. Développer avec SwiftUI pour Mac, par exemple, offre une expérience soignée au pixel près, mais nécessite des implémentations entièrement distinctes pour Windows et Linux, ce qui alourdit considérablement la charge d’ingénierie et de maintenance. Une entreprise, 1Password, a un jour eu besoin de quatre équipes distinctes avant de se consolider sur Electron.

Des alternatives comme Tauri et Wails s’attaquent à l’embonpoint d’Electron en exploitant la webview déjà présente dans le système d’exploitation (WebKit sur macOS, WebView2 sur Windows, WebKitGTK sur Linux), tandis que Rust ou Go gèrent les interactions natives avec le système. Cette approche donne des applications nettement plus légères : une application Tauri vide pèse environ 5 MB sur Mac, contre 268 MB pour le runtime de base typique d’Electron.

Cette efficacité introduit toutefois un compromis critique : la compatibilité. S’appuyer sur les webviews du système signifie que le rendu de votre application peut varier d’une plateforme à l’autre, avec des bogues ou des incohérences au niveau du système d’exploitation que vous ne maîtrisez pas. Slack, par exemple, utilisait à l’origine le moteur Safari intégré à macOS, mais est passé à Electron après avoir rencontré des problèmes de rendu impossibles à corriger dans d’anciennes versions de macOS.

En définitive, le « gain gratuit » apparent des alternatives plus légères se paie en cohérence et en contrôle. Si Tauri et Wails offrent des réductions de taille impressionnantes, ils réintroduisent la fragmentation même qu’Electron avait été conçu pour surmonter, obligeant les développeurs à arbitrer entre performances et expérience utilisateur prévisible.

Le véritable atout d’Electron, et aussi son défaut le plus agaçant, tient à son caractère autonome. Alors que les applications natives s’en remettent à des webviews système imprévisibles, comme le moteur de Safari sur macOS ou celui d’Edge sur Windows, Electron intègre son propre runtime Chromium. Cela garantit un environnement de rendu cohérent sur Windows, macOS et Linux, et évite aux développeurs les mauvaises surprises propres à chaque plateforme.

Ce contrôle a toutefois un coût. Lorsque Slack s’appuyait initialement sur le moteur Safari intégré à macOS, les anciennes versions du système présentant des bogues de Safari les laissaient impuissants. Le passage à Electron leur a offert une base de code unifiée et l’autonomie nécessaire pour livrer eux-mêmes les correctifs. Ce compromis explique pourquoi même des frameworks plus récents comme Tauri envisagent d’intégrer Chromium, reconnaissant ainsi la force essentielle d’Electron. Pour en savoir plus sur ses capacités, consultez Electron: Build Cross-Platform Desktop Apps.

Cependant, cette autonomie crée un problème de mises à jour tentaculaire. Chaque application Electron embarque sa propre copie de Chromium : un correctif apporté à Electron ou à Chromium lui-même n’atteint donc les utilisateurs qu’après la publication d’une mise à jour par chaque éditeur d’application. Par exemple, une mise à jour de macOS l’an dernier a provoqué des ralentissements à l’échelle du système dans les applications Electron, à cause d’un bogue d’Electron qui remplaçait du code d’interface privé d’Apple. Le correctif a dû être diffusé par chacune des applications concernées, ce qui illustre l’inefficacité de ce modèle de mise à jour distribué. Cette approche privilégiant la cohérence plutôt que l’élégance simplifie le développement, mais fragmente l’expérience utilisateur.

Pour les produits d’IA qui évoluent vite, l’attrait d’Electron est indéniable. Le code web et desktop partagé permet aux équipes de déployer des fonctionnalités sur Mac, Windows et Linux avec moins d’efforts dupliqués, ce qui rationalise le développement de produits comme Claude d’Anthropic et Codex d’OpenAI. Il s’agit de compromis d’ingénierie, et non d’une approbation universelle d’Electron.

OpenAI, par exemple, a remplacé son application Mac native ChatGPT par un client Codex basé sur Electron. L’application native d’origine pesait 159 MB, tandis que la nouvelle version Electron atteint 1,7 GB, bien qu’une part importante regroupe des outils Codex. Cela illustre le coût en ressources d’une base de code unifiée.

Même avec des outils de programmation IA avancés, le fardeau des clients natifs n’est pas supprimé. Les agents de code excellent pour générer des implémentations initiales, mais tester, corriger et prendre en charge plusieurs applications propres à chaque plateforme reste un défi majeur, qui multiplie le nombre de bogues et le travail de maintenance. Comme l’a déclaré l’un des créateurs de Claude Code : « trois applications, c’est trois fois plus de bogues à corriger et à prendre en charge. »

La règle pratique reste la suivante : pour les petits utilitaires où l’encombrement compte, envisagez Tauri ou Wails, qui peuvent produire des applications d’à peine 5 MB sur macOS. Pour les produits complexes et multiplateformes qui privilégient un comportement cohérent et des versions rapides sur Mac, Windows et Linux, Electron reste le choix le plus sûr et le plus prévisible.

Pourquoi les applications Electron consomment-elles autant de mémoire ?

Chaque application Electron intègre Chromium et exécute ses propres processus, ce qui engendre une surcharge même lorsque l’application est inactive.

Pourquoi des entreprises continuent-elles de choisir Electron ?

Electron offre un environnement Chromium cohérent et permet aux équipes de partager du code entre Mac, Windows, Linux et souvent le web.

Tauri est-il toujours plus léger qu’Electron ?

Les paquets d’applications Tauri peuvent être nettement plus petits, car Tauri utilise généralement la webview du système d’exploitation, mais le rendu peut varier selon la plateforme.

Quand une équipe doit-elle choisir le développement natif ?

Le développement natif peut être un choix pertinent lorsque les performances et l’expérience utilisateur propres à chaque plateforme justifient de maintenir des implémentations distinctes.