Electron et NW.js sont deux frameworks bien établis pour créer des applications de bureau multiplateformes à l’aide de technologies web. Tous deux associent Chromium et Node.js, ce qui permet aux développeurs de créer des applications avec HTML, CSS, JavaScript et des frameworks frontend familiers tels que React, Vue et Angular.
NW.js est en réalité le plus ancien des deux frameworks. Initialement connu sous le nom de node-webkit, le projet a démarré en 2011 et était accessible au public dès 2012. Electron a suivi en 2013, développé à l’origine par GitHub pour son éditeur de code Atom. Malgré son arrivée plus tardive, Electron a fini par devenir le framework le plus largement adopté pour les applications de bureau grand public.
Aujourd’hui, Electron fait fonctionner des applications majeures telles que Visual Studio Code, Slack, Discord, Notion et Figma. Il bénéficie également de la participation de grandes entreprises technologiques et d’une gouvernance assurée par l’OpenJS Foundation. Chez WebCatalog, nous avons choisi Electron comme socle de nos applications de bureau multiplateformes.
NW.js, quant à lui, est beaucoup moins visible parmi les grandes applications de productivité et les logiciels professionnels. Son utilisation reste particulièrement manifeste dans l’industrie du jeu vidéo, notamment dans les jeux indépendants et les titres créés avec RPG Maker.
Alors, comment ces deux frameworks se comparent-ils, et lequel les développeurs devraient-ils choisir ?
Electron et NW.js en un coup d’œil
Les deux frameworks permettent aux développeurs de créer des applications de bureau à l’aide de technologies web, mais ils abordent différemment l’architecture des applications, l’intégration native et la sécurité.
| Caractéristique | Electron | NW.js |
|---|---|---|
| Première apparition | 2013 | 2011–2012 |
| Développeur d’origine | GitHub | Intel Open Source Technology Center |
| Gouvernance et écosystème | OpenJS Foundation, avec d’importants contributeurs issus d’entreprises | Maintenu par la communauté, avec des origines chez Intel |
| Moteur de navigateur | Chromium | Chromium |
| Environnement d’exécution JavaScript | Node.js | Node.js |
| Plateformes de bureau | macOS, Windows, Linux | macOS, Windows, Linux |
| Architecture | Processus principal et processus de rendu | Architecture Chromium avec intégration directe de Node.js |
| Accès à Node.js | Processus principal et intégration contrôlée dans les processus de rendu | Accès direct depuis les pages d’application autorisées |
| Taille des applications | Relativement importante | Relativement importante |
| Performances | Dépendent de l’application | Dépendent de l’application |
| Sécurité | Exécution en bac à sable, isolation des contextes, IPC | Accès à Node configurable et isolation des frames |
| Adoption | Largement utilisé dans les applications de bureau grand public | Écosystème plus restreint, adoption notable dans le jeu vidéo |
| Prise en charge mobile | Aucune prise en charge officielle | Aucune prise en charge officielle |
Les distinctions les plus importantes ne concernent ni les performances ni la taille des applications. Les deux frameworks embarquent Chromium et Node.js : leurs besoins en ressources sont donc globalement comparables. Les principales différences portent plutôt sur l’architecture, les frontières de sécurité, les outils de développement et le soutien de l’écosystème.
Historique : NW.js est arrivé en premier, mais Electron est devenu plus populaire
NW.js a été l’un des premiers projets à démontrer que les développeurs pouvaient combiner Node.js avec les technologies de navigateur pour créer des applications de bureau. Initialement appelé node-webkit, il est issu de l’Open Source Technology Center d’Intel. Son développement a commencé en 2011 et des versions publiques sont apparues dès 2012.
Son idée centrale était simple : permettre au JavaScript exécuté dans un environnement semblable à un navigateur d’accéder directement aux modules Node.js. Il devenait ainsi possible de développer des applications de bureau avec des technologies web familières, sans créer d’interface native traditionnelle.
Electron est arrivé en 2013 sous le nom d’Atom Shell. GitHub l’a développé pour faire fonctionner Atom, son éditeur de code, dont la bêta publique a été lancée en 2014. Electron a été conçu comme une alternative aux frameworks de bureau fondés sur le web disponibles à l’époque, notamment node-webkit et Chromium Embedded Framework.
Bien que les deux frameworks aient partagé l’objectif de rendre le développement d’applications de bureau accessible aux développeurs web, Electron a adopté une architecture différente, séparant les fonctionnalités propres à l’application du contenu web. Cette approche est devenue de plus en plus attrayante à mesure que les développeurs créaient des applications plus complexes.
Electron a ensuite été adopté par des startups et de grandes entreprises technologiques. GitHub, Slack, Microsoft et d’autres organisations ont contribué à son développement et à son écosystème. En 2019, Electron a rejoint l’OpenJS Foundation, passant de la propriété de GitHub à celle d’une fondation open source neutre.
Aujourd’hui, Electron fonctionne selon un modèle de gouvernance établi, avec des groupes de travail consacrés à la sécurité, aux versions, aux API, aux mises à niveau de Chromium et de Node.js, ainsi qu’à d’autres domaines. Des ingénieurs liés à des organisations telles que Microsoft et Slack ont participé à sa maintenance et à sa gouvernance.
NW.js a lui aussi des origines en entreprise, puisqu’il a été créé chez Intel. Toutefois, son écosystème actuel est plus restreint et ne bénéficie pas d’une participation visible aussi étendue de la part des grands éditeurs de logiciels de bureau.
Cet historique illustre une distinction importante : être le premier ne garantit pas une position dominante à long terme. NW.js a contribué à établir le concept de création d’applications de bureau avec Chromium et Node.js, mais Electron a attiré un écosystème plus vaste de développeurs, de mainteneurs et d’entreprises utilisatrices.
Pour en savoir plus, consultez la rétrospective des 10 ans d’Electron, l’annonce de l’arrivée d’Electron au sein de l’OpenJS Foundation et l’historique du projet node-webkit.
Architecture : processus principal ou intégration directe de Node.js
Electron utilise une architecture multiprocessus héritée de Chromium. Chaque application Electron possède un processus principal chargé de gérer les fenêtres, les événements du cycle de vie de l’application, les intégrations avec le système d’exploitation et les fonctionnalités privilégiées. Le contenu web s’exécute dans des processus de rendu distincts, qui communiquent avec le processus principal par communication interprocessus (IPC).
Cela crée une distinction entre la logique applicative et le code de l’interface utilisateur. Un processus de rendu se comporte généralement comme un environnement de navigateur classique, tandis que le processus principal gère les opérations nécessitant un accès à Node.js ou aux API natives. Electron fournit également des scripts de préchargement et l’API contextBridge, qui permettent aux développeurs d’exposer certaines fonctionnalités au processus de rendu sans lui accorder un accès illimité à Node.js.
NW.js adopte une autre approche. Il a été conçu pour rendre les fonctionnalités de Node.js directement accessibles au sein des applications web. Dans une page d’application autorisée, les développeurs peuvent accéder aux modules Node.js à l’aide d’API JavaScript familières, sans définir une interface IPC distincte pour chaque opération.
Par exemple, une application NW.js distribuée avec ses fichiers locaux peut utiliser Node.js directement depuis un script exécuté dans sa page :
const fs = require('node:fs');
const content = fs.readFileSync('notes.txt', 'utf8');
document.body.textContent = content;
Cette simplicité constitue l’un des principaux atouts de NW.js. Les développeurs peuvent combiner les API du navigateur et les fonctionnalités de Node.js sans nécessairement répartir leur code en couches applicatives distinctes. NW.js prend également en charge des contextes JavaScript séparés et un mode à contexte mixte, offrant de la souplesse dans les interactions entre les fonctionnalités du navigateur et celles de Node.js.
Electron encourage généralement une séparation plus explicite. Pour lire un fichier depuis le processus de rendu, une application Electron sécurisée classique exposerait une opération limitée au moyen d’un script de préchargement et gérerait l’accès au système de fichiers dans le processus principal.
Cette approche nécessite du code supplémentaire, mais elle rend plus explicite la frontière entre les fonctionnalités privilégiées de l’application et le contenu web. Pour les applications complexes, cette séparation peut améliorer la maintenabilité et faciliter la compréhension des responsabilités en matière de sécurité.
Aucune de ces architectures n’est universellement meilleure. NW.js peut sembler plus simple pour les petites applications ou les projets qui tirent parti d’une intégration directe de Node.js. Electron fournit une structure qui peut être particulièrement utile à mesure qu’une application gagne en complexité.
Performances, utilisation de la mémoire et taille des applications
Comme Electron et NW.js embarquent tous deux Chromium et Node.js, aucun ne dispose d’un avantage architectural intrinsèque comparable à la différence de taille entre Electron et Tauri.
Même une application simple créée avec l’un ou l’autre de ces frameworks doit distribuer un environnement d’exécution conséquent. Les deux frameworks peuvent également créer plusieurs processus Chromium, ce qui augmente la consommation de mémoire, mais contribue à isoler les charges de travail et à améliorer la réactivité.
L’intégration directe de Node.js à l’environnement du navigateur dans NW.js peut réduire le recours à l’IPC pour certaines opérations. Selon la configuration des contextes, le code JavaScript peut interagir directement avec les fonctionnalités de Node.js, ce qui simplifie certaines opérations et peut réduire le surcoût de communication.
Electron sépare les opérations privilégiées du code de rendu, ce qui introduit des communications IPC lorsque les frontières entre processus sont franchies. Cela ne signifie toutefois pas qu’Electron est intrinsèquement plus lent. Le surcoût peut être négligeable pour les interactions ordinaires avec l’interface utilisateur, et cette séparation peut aider à maintenir les traitements backend coûteux à l’écart du processus de rendu.
En pratique, les performances d’une application dépendent fortement de la manière dont les développeurs utilisent Chromium, gèrent les processus en arrière-plan, mettent en œuvre le rendu et gèrent l’état de l’application.
Pour obtenir des comparaisons pertinentes, les développeurs devraient évaluer :
- Le temps de démarrage : le délai avant que l’application devienne interactive.
- L’utilisation de la mémoire : la consommation au repos et lors de charges de travail réalistes.
- L’utilisation du processeur : la consommation de ressources pendant le rendu et les opérations en arrière-plan.
- La taille de l’application : la taille du téléchargement et l’espace de stockage nécessaire après installation.
- La réactivité : le comportement de l’interface pendant les tâches gourmandes en ressources.
Aucun des deux frameworks ne devrait être considéré comme systématiquement plus rapide sans effectuer des mesures sur une application représentative. Les différences de versions de Chromium, de configurations de compilation, de modules natifs et d’architecture applicative peuvent toutes influencer les résultats des tests de performance.
Pour les développeurs qui cherchent avant tout à réduire la taille de leur application, passer d’Electron à NW.js a peu de chances d’offrir les économies spectaculaires associées à l’adoption d’un framework utilisant la WebView du système.
Sécurité : différentes approches de l’accès natif
La sécurité est l’une des différences les plus importantes entre Electron et NW.js, en particulier pour les applications qui affichent des sites web distants ou d’autres contenus non fiables.
Electron propose plusieurs mécanismes de sécurité, notamment le bac à sable de Chromium, l’isolation des contextes et la possibilité de désactiver l’intégration de Node.js dans les processus de rendu. Les versions modernes d’Electron activent par défaut des protections importantes, et la documentation du projet consacrée à la sécurité recommande vivement de séparer les API natives privilégiées du contenu distant.
NW.js permet un accès plus direct à Node.js depuis les pages d’application autorisées, ce qui peut simplifier le développement, mais exige aussi de réfléchir soigneusement aux contenus qui reçoivent ces privilèges.
NW.js distingue les frames normales de celles où Node.js est activé. Il prend également en charge des paramètres tels que node-remote pour contrôler quelles URL distantes peuvent accéder aux fonctionnalités de Node.js. Son composant webview peut afficher du contenu invité dans un processus distinct sans lui accorder automatiquement les privilèges de l’application.
| Aspect de sécurité | Electron | NW.js |
|---|---|---|
| Accès privilégié à Node.js | Principalement dans le processus principal et au moyen de passerelles contrôlées | Disponible directement dans les contextes d’application autorisés |
| Isolation du contenu distant | Processus de rendu et contenus web en bac à sable | Frames normales et webviews isolées |
| Exposition des API natives | IPC et contextBridge | Contextes Node et accès configurable |
| Bac à sable de Chromium | Pris en charge avec des paramètres sécurisés par défaut | Dépend du type de frame et de la configuration |
| Responsabilité du développeur | Valider les communications IPC, la navigation, les autorisations et les API exposées | Contrôler les frames privilégiées, l’accès à Node et le contenu distant |
Ni Electron ni NW.js ne doivent être automatiquement considérés comme des navigateurs généralistes sécurisés. Les applications qui affichent des sites web tiers quelconques nécessitent des mesures de sécurité supplémentaires, quel que soit le framework.
Pour les applications développées entièrement autour de contenus locaux fiables, l’intégration directe de NW.js peut être pratique. Pour celles qui ont besoin d’une séparation forte entre le code privilégié et le contenu web non fiable, l’architecture d’Electron peut rendre ces frontières plus explicites.
En définitive, la sécurité dépend de la conception de l’application, de sa configuration, de la gestion des dépendances et de la rapidité avec laquelle les développeurs appliquent les mises à jour de sécurité.
Adoption : Electron domine les applications de bureau grand public
L’une des différences les plus significatives entre Electron et NW.js est leur adoption par les développeurs de logiciels de bureau.
Bien qu’il soit le projet le plus récent, Electron s’est imposé comme un framework courant pour les applications de bureau en production. Son adoption s’étend aux outils de développement, aux plateformes de communication, aux logiciels de productivité, aux applications de conception et aux utilitaires professionnels.
Voici quelques exemples bien connus :
| Entreprise | Application Electron |
|---|---|
| Microsoft | Visual Studio Code |
| Salesforce | Slack |
| Discord | Discord |
| Notion | Notion |
| Figma | Figma |
| GitHub | GitHub Desktop |
| Signal | Signal Desktop |
| Postman | Postman |
Ces produits démontrent qu’Electron peut prendre en charge des applications de bureau sophistiquées utilisées par des millions de personnes. Son adoption a également contribué à un vaste écosystème de bibliothèques, de documentation, d’outils de débogage et de solutions de création de paquets.
La participation des entreprises constitue un autre avantage. Electron a été développé à l’origine par GitHub, puis a attiré les contributions d’ingénieurs de grandes entreprises technologiques. Sa gouvernance par l’OpenJS Foundation fournit une structure organisationnelle pour la collaboration, la maintenance de la sécurité, la gestion des versions et le développement à long terme.
Cela ne signifie pas que chaque entreprise utilisant Electron contribue directement au framework, ni qu’Electron sera toujours mieux maintenu. Toutefois, un framework largement utilisé et soutenu par un groupe diversifié d’acteurs commerciaux peut bénéficier d’un investissement collectif en ingénierie et d’une expérience concrète de la production.
NW.js présente un profil d’adoption différent. Bien qu’il ait servi à créer des applications de bureau, relativement peu d’applications modernes de productivité ou de logiciels professionnels de premier plan déclarent publiquement utiliser NW.js. De nombreuses applications traditionnellement citées dans les vitrines de NW.js sont des projets plus anciens, ce qui rend ces listes moins utiles pour évaluer son adoption actuelle.
Cela ne signifie pas que NW.js est abandonné ou inutilisé. Il continue de recevoir des versions intégrant des versions actualisées de Chromium et de Node.js. Toutefois, son écosystème visible est considérablement plus restreint que celui d’Electron dans le domaine des logiciels de bureau grand public.
Pour les développeurs qui choisissent un framework pour une nouvelle application commerciale, cette distinction est importante. Un écosystème plus vaste facilite généralement la recherche de solutions existantes, le recrutement de développeurs possédant une expérience pertinente et la résolution des problèmes en production.
La popularité d’Electron ne le rend pas techniquement supérieur à tous égards, mais son adoption plus large et la participation des entreprises constituent des avantages pratiques à ne pas négliger.
Vous pouvez découvrir d’autres exemples dans la vitrine officielle des applications Electron.
Là où NW.js reste populaire : les jeux indépendants
Bien que NW.js soit peu représenté parmi les grandes applications modernes de productivité, il conserve une présence notable dans le développement de jeux vidéo, en particulier chez les développeurs indépendants.
L’une des raisons est son intégration à des outils de création de jeux tels que RPG Maker MV. Les jeux créés avec RPG Maker MV peuvent utiliser NW.js comme environnement d’exécution de bureau, ce qui permet aux jeux fondés sur HTML5 et JavaScript de fonctionner comme des applications autonomes.
Cela signifie que les développeurs peuvent utiliser NW.js indirectement, par l’intermédiaire de leur moteur de jeu, plutôt que de le sélectionner comme framework généraliste pour applications de bureau.
Il existe également des éléments indépendants montrant que NW.js continue d’apparaître dans des jeux récemment publiés. SteamDB recense les jeux utilisant NW.js en examinant automatiquement les signatures technologiques présentes dans leurs fichiers distribués. Sa base de données comprend des jeux sortis en 2025 et 2026, ce qui témoigne d’une utilisation continue sans dépendre entièrement de vitrines d’applications potentiellement obsolètes.
Voici quelques exemples associés à NW.js :
| Jeu | Genre | Sortie sur Steam |
|---|---|---|
| Look Outside | RPG d’horreur | Mars 2025 |
| OMORI | RPG | Décembre 2020 |
| CrossCode | Action-RPG | Septembre 2018 |
| Fear & Hunger | RPG d’horreur | Décembre 2018 |
| Ib | Aventure horrifique | Avril 2022 |
| Saihate Station | Aventure | Mars 2025 |
| Sheepy: A Short Adventure | Jeu de plateformes | Février 2024 |
Source : détection de la technologie NW.js par SteamDB.
SteamDB identifie automatiquement les technologies à partir des fichiers des jeux. Certaines détections peuvent donc contenir des erreurs ou correspondre à une dépendance incluse plutôt qu’à un environnement d’exécution délibérément choisi par le développeur. La présence de NW.js ne permet pas non plus de déterminer quelle version du framework un jeu utilise, ni si son développeur le maintient activement.
Néanmoins, ces exemples montrent que NW.js fait toujours partie de l’écosystème moderne du développement de jeux vidéo.
Cela crée une distinction intéressante entre les deux frameworks. Electron est très visible dans les applications de bureau grand public, en particulier les outils de productivité et de développement. NW.js est moins présent dans ces catégories, mais continue d’apparaître dans des jeux développés de manière indépendante.
Pour les développeurs qui créent des logiciels professionnels, des outils de communication ou des applications de productivité complexes, l’écosystème d’Electron peut être plus pertinent. Pour ceux qui travaillent avec RPG Maker ou maintiennent des jeux construits autour de NW.js, le framework le plus ancien reste un choix éprouvé et pratique.
Expérience de développement, outils et maintenance à long terme
Les deux frameworks prennent en charge les technologies frontend modernes et les paquets Node.js, ce qui les rend accessibles aux développeurs familiarisés avec le développement web. Toutefois, Electron dispose d’un écosystème considérablement plus vaste consacré aux logiciels de bureau généralistes.
NW.js propose un modèle de développement relativement simple. Une application élémentaire peut être définie à l’aide d’un manifeste package.json et d’un point d’entrée HTML. Les développeurs peuvent accéder directement aux modules Node.js depuis les pages d’application autorisées et utiliser les API de NW.js pour gérer les fenêtres, les menus, les icônes de la zone de notification et d’autres fonctionnalités de bureau.
Electron nécessite généralement davantage de structure initiale. Les développeurs créent un point d’entrée pour le processus principal, configurent les fenêtres de l’application et gèrent la communication entre le processus principal et les processus de rendu. Cela peut sembler plus compliqué pour les petites applications, mais encourage également à organiser les fonctionnalités de l’application en couches distinctes.
Electron bénéficie d’outils éprouvés tels qu’Electron Forge et electron-builder, qui proposent des solutions pour créer les paquets, signer, distribuer et mettre à jour les applications. Sa large adoption signifie également que les développeurs peuvent trouver davantage d’exemples et de discussions communautaires sur les problèmes avancés du développement d’applications de bureau.
NW.js fournit des outils de création de paquets tels que nw-builder et prend en charge la création manuelle de paquets. Il expose également des API issues de l’architecture des applications et des extensions de Chromium, ce qui peut être intéressant pour les projets qui utilisent déjà ces API.
Les deux frameworks exigent que les développeurs gèrent les différences entre systèmes d’exploitation, la signature du code, la compatibilité des modules natifs et les mises à jour des applications. Aucun n’élimine la complexité de la distribution de logiciels de bureau destinés à la production.
La taille et la composition de l’écosystème deviennent particulièrement importantes pour la maintenance à long terme. Les équipes qui créent des applications commerciales peuvent avoir besoin de solutions pour la signature du code, les mises à jour automatiques, les rapports de plantage, l’accessibilité, les intégrations natives et les bugs propres à chaque plateforme.
L’adoption plus large d’Electron parmi les grands éditeurs de logiciels facilite la recherche de pratiques établies et de solutions réutilisables pour nombre de ces besoins. NW.js reste capable de les satisfaire, mais les développeurs peuvent trouver moins d’exemples ou d’intégrations maintenues pour des fonctionnalités de bureau spécialisées.
Pour un projet destiné à être maintenu pendant de nombreuses années, la maturité de l’écosystème et la continuité des investissements méritent autant d’attention que les API du framework ou les résultats des tests de performance.
Pourquoi nous choisissons Electron chez WebCatalog
Chez WebCatalog, nous avons choisi Electron parce que son architecture correspond étroitement aux exigences de nos produits. WebCatalog permet aux utilisateurs de transformer des sites web en applications de bureau, de gérer plusieurs comptes indépendamment et d’organiser leurs applications sur macOS, Windows et Linux.
Contrairement aux développeurs qui créent une application de bureau classique avec un frontend qu’ils contrôlent entièrement, nous devons prendre en charge des sites web créés par des milliers de développeurs différents. Ces sites peuvent s’appuyer sur différents systèmes d’authentification, mécanismes de stockage, API de navigateur, fonctionnalités multimédias et applications JavaScript complexes.
Electron et NW.js utilisent tous deux Chromium : ils offrent donc des avantages similaires en matière de compatibilité du moteur de navigateur. Pour nous, la distinction réside dans le degré de contrôle fourni par le framework sur les fenêtres de l’application, les sessions de navigateur, la navigation, les autorisations et la séparation entre le code privilégié de l’application et le contenu distant.
Electron propose un ensemble d’API matures pour répondre à ces besoins. Ses interfaces BrowserWindow, webContents et session nous permettent de gérer le comportement du navigateur à un niveau relativement bas. Les partitions de session persistantes sont particulièrement importantes, car elles permettent aux utilisateurs de rester connectés à plusieurs comptes sur un même site sans partager leurs cookies ni les autres données de session.
NW.js prend également en charge les webviews intégrées, la gestion des cookies et les partitions de stockage : ces fonctionnalités ne sont donc pas exclusives à Electron. Toutefois, le processus dédié à l’application et les API éprouvées de gestion du navigateur d’Electron offrent une architecture bien adaptée à nos besoins.
La sécurité est un autre facteur important. Comme WebCatalog affiche des sites web tiers que nous ne contrôlons pas, nous devons séparer soigneusement le contenu distant des fonctionnalités privilégiées de l’application. Le modèle de processus d’Electron, l’isolation des contextes et les mécanismes IPC nous aident à maintenir cette séparation, même si nous devons toujours mettre en place et maintenir nous-mêmes des mesures de sécurité appropriées.
Enfin, l’écosystème d’Electron rend le développement et la maintenance multiplateformes plus pratiques. Nos applications doivent fonctionner sur macOS, Windows et Linux, avec la prise en charge des fonctionnalités propres à chaque plateforme, de la création de paquets, de la signature et des mises à jour. Les outils, la documentation et la vaste adoption d’Electron dans des applications réelles constituent une base solide pour ce travail.
Nous accordons également de l’importance à l’écosystème de développement à long terme d’Electron. La participation de grandes entreprises technologiques et sa gouvernance par l’OpenJS Foundation renforcent notre confiance dans la disponibilité des ressources techniques, de la maintenance de la sécurité et du soutien communautaire à mesure que nos produits évoluent.
Nous reconnaissons les inconvénients d’Electron, notamment la taille des applications et leurs besoins en ressources. Plutôt que de remplacer le framework, nous continuons d’explorer des moyens de réduire les surcoûts inutiles. Par exemple, nous avons mis en œuvre des clones APFS pour réduire l’espace disque occupé par les applications Mac générées.
Notre décision ne repose pas sur l’idée que NW.js serait incapable de prendre en charge des logiciels sophistiqués. Les deux frameworks offrent la cohérence de Chromium à laquelle nous tenons. Pour WebCatalog, l’architecture d’Electron, ses mécanismes de sécurité, son adoption plus large dans les applications grand public et son écosystème d’ingénierie établi en font le choix le mieux adapté.
Dans quels cas NW.js reste pertinent
Bien qu’Electron dispose d’un écosystème plus vaste, NW.js conserve certains avantages importants que les développeurs devraient prendre en compte.
Sa caractéristique la plus distinctive est la possibilité d’accéder directement à Node.js depuis les contextes de navigateur autorisés. Pour les développeurs qui convertissent une application web existante en application de bureau, cela peut constituer un moyen pratique d’ajouter l’accès au système de fichiers, des intégrations avec le système d’exploitation et d’autres fonctionnalités natives sans concevoir de couche de communication distincte.
NW.js peut être un bon choix dans les situations suivantes :
- Créer des jeux avec une chaîne d’outils existante fondée sur NW.js. Les développeurs qui utilisent RPG Maker MV ou maintiennent des projets dépendant de NW.js peuvent avoir peu de raisons de changer de framework.
- L’intégration directe de Node.js est souhaitable. L’application peut tirer parti d’un accès direct aux fonctionnalités de Node.js au sein de son interface de confiance.
- L’application est relativement simple. Un petit projet peut ne pas avoir besoin de la séparation plus explicite d’Electron entre la logique principale et la logique de rendu.
- Le projet utilise déjà NW.js. Une migration vers Electron peut apporter peu d’avantages si l’application existante est stable et bien maintenue.
- Certaines API d’application de Chromium sont importantes. NW.js donne accès aux API Chrome prises en charge qui peuvent être utiles pour certaines applications.
NW.js reste également activement maintenu. Ses mises à jour continues de Chromium montrent qu’il continue d’évoluer aux côtés de la plateforme web.
Pour les développeurs qui maintiennent une application ou un jeu NW.js existant, un passage à Electron nécessiterait d’évaluer les différences architecturales, les changements de création des paquets et les exigences de compatibilité. À moins d’un avantage technique ou commercial évident, conserver le framework existant peut être plus pratique.
Electron ou NW.js : lequel choisir ?
Les deux frameworks permettent de créer des applications de bureau multiplateformes. Pour les nouveaux projets, le choix dépend en grande partie de la manière dont les développeurs souhaitent structurer leur code et de l’écosystème qui répond le mieux à leurs besoins.
| Votre priorité | Meilleur point de départ | Pourquoi |
|---|---|---|
| Applications de bureau volumineuses et complexes | Electron | Architecture et écosystème éprouvés |
| Logiciels de productivité ou professionnels grand public | Electron | Adoption beaucoup plus large dans ces catégories |
| Pérennité de l’écosystème et participation des entreprises | Electron | OpenJS Foundation et grands contributeurs du secteur |
| Jeux créés avec RPG Maker MV | NW.js | Intégration et chaîne d’outils éprouvées |
| Accès direct à Node.js depuis les pages de l’application | NW.js | Caractéristique architecturale fondamentale |
| Séparation explicite entre l’interface utilisateur et le code privilégié | Electron | Modèle processus principal/processus de rendu et IPC |
| Outils complets de création de paquets et de distribution | Electron | Écosystème d’outils mature |
| Application NW.js existante | NW.js | Évite une migration inutile |
| Cohérence de Chromium entre les plateformes de bureau | L’un ou l’autre | Tous deux embarquent Chromium |
| Taille minimale de l’application | Aucun avantage net pour l’un ou l’autre | Tous deux embarquent Chromium et Node.js |
| Gestion des sessions de navigateur et des fenêtres | Electron | API dédiées et matures |
| Nombreuses ressources communautaires et exemples | Electron | Adoption plus large dans les applications grand public |
Pour la plupart des équipes qui démarrent une nouvelle application de bureau d’envergure, Electron constitue le choix par défaut le plus solide. Son architecture, son écosystème, ses recommandations de sécurité, la participation des entreprises et sa vaste adoption en production en font un framework pratique pour le développement à long terme.
NW.js reste à envisager pour les projets qui tirent parti d’une intégration directe de Node.js, les processus de développement de jeux qui en dépendent déjà ou les bases de code NW.js établies. Il peut être plus simple pour certains cas d’usage, et son socle Chromium offre une large compatibilité avec la plateforme web.
Les développeurs doivent également garder à l’esprit qu’aucun des deux frameworks n’est particulièrement léger. Si la petite taille de l’application et une faible consommation de ressources de base sont les principales préoccupations, des alternatives telles que Tauri peuvent mériter d’être envisagées.
Conclusion
Electron et NW.js partagent plus de similitudes que de différences. Tous deux associent Chromium et Node.js pour permettre aux développeurs de créer des applications de bureau multiplateformes à l’aide de technologies web familières. Tous deux prennent en charge les frameworks JavaScript modernes, l’intégration native au système d’exploitation et des expériences de bureau sophistiquées.
NW.js est arrivé en premier, proposant son approche de l’association de Node.js aux technologies web avant l’existence d’Electron. Toutefois, Electron est ensuite devenu le framework le plus largement adopté pour les applications de bureau grand public, bénéficiant de l’investissement initial de GitHub, des contributions de grandes entreprises technologiques et d’une gouvernance assurée par l’OpenJS Foundation.
Leurs profils d’adoption sont sensiblement différents. Electron fait fonctionner des applications populaires de productivité, de communication et de développement utilisées par des millions de personnes. NW.js est moins visible sur ce marché, mais conserve une présence significative dans le jeu indépendant, notamment dans les titres fondés sur RPG Maker et les jeux récemment publiés.
Chez WebCatalog, nous faisons le même choix de framework que de nombreux grands développeurs de logiciels de bureau. Electron nous apporte la cohérence de Chromium, les capacités de gestion du navigateur, l’architecture de sécurité et les outils multiplateformes nécessaires pour prendre en charge une grande variété d’applications web sur macOS, Windows et Linux.
NW.js n’est pas obsolète, et son utilisation continue dans le développement de jeux montre qu’il reste utile. Mais pour les développeurs qui démarrent une nouvelle application de bureau généraliste, l’écosystème plus vaste d’Electron, ses outils éprouvés, la participation des entreprises et sa communauté plus importante en font le choix par défaut le plus pratique.
En définitive, le meilleur choix dépend des exigences de l’application, de l’expérience de l’équipe de développement et du coût de maintenance du logiciel à long terme.
