Electron et Chromium Embedded Framework (CEF) sont deux technologies éprouvées permettant d’intégrer Chromium dans des applications de bureau. Toutes deux permettent aux développeurs de créer des logiciels qui affichent des sites et des interfaces web modernes sous macOS, Windows et Linux. Elles répondent toutefois à des besoins fondamentalement différents.
Electron est un framework complet de développement d’applications de bureau qui combine Chromium, Node.js et les API natives du système d’exploitation. Les développeurs peuvent créer des applications entières en JavaScript, TypeScript, HTML et CSS sans avoir besoin d’une grande expérience en programmation native. CEF, en revanche, est un framework permettant d’intégrer Chromium dans des applications existantes ou nouvelles, généralement écrites en C++ ou dans d’autres langages natifs.
Les deux technologies sont largement utilisées dans des logiciels en production. Electron fait fonctionner des applications comme Visual Studio Code, Slack, Discord et Notion, tandis que CEF est utilisé dans des produits tels que Spotify, Steam et OBS Studio. Chez WebCatalog, nous avons choisi Electron pour créer nos applications de bureau multiplateformes.
Quelles sont donc les différences, et dans quels cas est-il pertinent de choisir l’une plutôt que l’autre ?
Electron et CEF en un coup d’œil
Bien qu’Electron et CEF utilisent tous deux Chromium, ils diffèrent considérablement par leur architecture, l’expérience de développement et les applications auxquelles ils sont destinés.
| Caractéristique | Electron | Chromium Embedded Framework (CEF) |
|---|---|---|
| Première version | 2013 | 2008 |
| Objectif principal | Créer des applications de bureau complètes | Intégrer Chromium dans d’autres applications |
| Moteur de navigateur | Chromium | Chromium |
| Langages principaux | JavaScript, TypeScript | C, C++, avec des liaisons tierces |
| Node.js inclus | Oui | Non |
| Intégration native | API Electron et modules natifs Node.js | Intégration directe avec le code natif |
| Structure de l’application | Processus principal et processus de rendu | Application hôte avec des sous-processus Chromium |
| Rendu hors écran | Possible à l’aide de solutions personnalisées | Prise en charge intégrée dans l’API |
| Taille de l’application | Généralement importante | Dépend de l’intégration, mais Chromium occupe un espace conséquent |
| Performances | Dépendent de l’application | Dépendent de l’application et de l’intégration |
| Prise en charge multiplateforme | macOS, Windows, Linux | macOS, Windows, Linux |
| Écosystème de création de paquets | Electron Forge, electron-builder | Généralement géré par l’application hôte |
| Cas d’usage privilégié | Applications de bureau basées sur JavaScript | Applications natives nécessitant du contenu web intégré |
La distinction essentielle est qu’Electron fournit un framework d’application, tandis que CEF fournit un framework d’intégration de navigateur. Ils ne sont pas nécessairement des substituts directs, car ils interviennent à des niveaux d’abstraction différents.
Architecture : framework complet ou navigateur intégré
Electron combine Chromium et Node.js dans un environnement d’exécution unifié pour les applications. Les développeurs créent un processus principal qui gère les fenêtres de l’application, les événements de son cycle de vie et les fonctionnalités natives, tandis que les processus de rendu prennent en charge l’interface web.
Cette architecture permet aux développeurs d’écrire l’essentiel de leurs applications à l’aide d’outils JavaScript et TypeScript familiers. Electron fournit des API pour créer des fenêtres, gérer les sessions du navigateur et les menus, afficher des notifications, accéder aux boîtes de dialogue système et interagir avec le système d’exploitation.
CEF adopte une approche différente. Au lieu de fournir un framework complet d’application de bureau, il permet aux développeurs d’intégrer Chromium dans une application qu’ils créent et contrôlent eux-mêmes.
Par exemple, un développeur qui crée une application native en C++ peut utiliser CEF pour afficher du contenu web dans une fenêtre existante de l’application. L’interface qui l’entoure, le cycle de vie de l’application, les services en arrière-plan et les autres fonctionnalités natives restent sous le contrôle du développeur.
CEF fournit des API pour gérer les instances de navigateur, la navigation, le chargement des ressources, l’exécution de JavaScript et la communication entre le navigateur et l’application native. Il utilise également l’architecture multiprocessus de Chromium, avec des processus distincts pour le rendu et les autres fonctionnalités du navigateur.
Cette distinction influence la manière dont les développeurs structurent leurs applications. Avec Electron, l’application est généralement construite autour de Chromium et de Node.js. Avec CEF, Chromium constitue habituellement un composant au sein d’une application plus vaste.
CEF peut également servir à créer des applications dont l’interface repose principalement sur les technologies web, mais les développeurs doivent alors mettre en place eux-mêmes une plus grande partie de l’infrastructure qui entoure l’application.
Un détail historique intéressant : les premières versions d’Electron et de NW.js utilisaient CEF. Electron a finalement choisi une intégration plus directe avec Chromium, car l’abstraction fournie par CEF rendait certaines fonctionnalités difficiles à mettre en œuvre, notamment l’intégration poussée de Node.js.
Pour les développeurs qui souhaitent disposer d’un framework complet afin de créer des applications de bureau à l’aide des technologies web, Electron constitue généralement un point de départ plus simple. Pour ceux qui possèdent déjà une application native et souhaitent y ajouter des fonctionnalités web, CEF peut être le choix le plus naturel.
Expérience de développement : JavaScript ou développement natif
L’un des principaux avantages d’Electron est son accessibilité. Les développeurs qui connaissent le développement web moderne peuvent exploiter leurs compétences existantes pour créer des applications de bureau sans apprendre le C++ ni les frameworks d’interface propres à chaque plateforme.
L’intégration de Node.js dans Electron donne accès à un vaste écosystème de paquets pour les opérations sur le système de fichiers, les communications réseau, les bases de données, les processus en arrière-plan et d’autres fonctionnalités. Des technologies frontend populaires comme React, Vue, Svelte et Angular peuvent être utilisées sans modifications architecturales majeures.
CEF est principalement conçu autour d’API C et C++. Bien qu’il existe des liaisons tierces pour des langages tels que C#, Java, Python et Delphi, les développeurs doivent tout de même comprendre l’architecture de l’application native ainsi que les exigences de CEF en matière de processus, de threads et de cycle de vie.
Pour une équipe qui assure déjà la maintenance d’une application native, cela peut être un avantage plutôt qu’un inconvénient. CEF permet aux développeurs d’introduire une interface web moderne sans réécrire le code natif existant ni adopter un framework d’application entièrement nouveau.
En revanche, pour une équipe spécialisée en JavaScript qui démarre une nouvelle application de bureau, CEF nécessite généralement davantage de travail de configuration et d’intégration native.
La différence concerne également les outils. Electron bénéficie d’outils éprouvés tels qu’Electron Forge et electron-builder, qui simplifient la création de paquets, la signature du code, la distribution des applications et les mises à jour. CEF fournit des distributions binaires et des exemples, mais les développeurs sont généralement responsables de l’intégration du framework dans leurs propres systèmes de compilation et de déploiement.
Cela ne signifie pas que CEF est moins performant fonctionnellement. Cela reflète simplement sa vocation de composant intégrable plutôt que de plateforme complète de développement d’applications.
Performances, utilisation de la mémoire et taille des applications
Puisqu’Electron et CEF utilisent tous deux Chromium, aucun des deux n’élimine automatiquement le surcoût en ressources associé à l’exécution d’un moteur de navigateur moderne.
Les deux technologies peuvent utiliser plusieurs processus pour le rendu, l’accélération GPU, les communications réseau et les autres fonctionnalités du navigateur. La consommation de mémoire et l’utilisation du processeur dépendent fortement du contenu affiché, du nombre d’instances de navigateur actives et de la manière dont l’application gère ses ressources.
CEF peut offrir davantage de souplesse lorsqu’il est intégré à une application native existante. Les développeurs peuvent réserver Chromium aux parties de l’interface qui nécessitent des technologies web, tout en implémentant les autres fonctionnalités directement en code natif.
Par exemple, une application graphique peut utiliser CEF pour un panneau de paramètres ou une interface web intégrée, tout en conservant un moteur de rendu, un traitement des documents et d’autres fonctionnalités sensibles aux performances en code natif.
Les applications Electron peuvent également exécuter du code natif au moyen d’extensions Node.js, de processus externes ou de modules natifs. Toutefois, l’architecture d’Electron est généralement orientée vers la création de l’application elle-même avec des technologies web.
Une fonctionnalité particulièrement utile de CEF est le rendu hors écran. Au lieu d’afficher le contenu web dans une fenêtre de navigateur classique, CEF peut effectuer le rendu dans des tampons que l’application hôte traite et affiche elle-même. Cette fonctionnalité est précieuse pour les moteurs de jeux, les logiciels de streaming et les outils dotés de systèmes de rendu personnalisés.
Electron peut prendre en charge des processus de rendu spécialisés grâce à des intégrations supplémentaires, mais CEF propose le rendu hors écran comme une fonctionnalité éprouvée de son API d’intégration.
Pour les développeurs qui évaluent les performances, les mesures les plus utiles comprennent :
- Temps de démarrage : la rapidité avec laquelle l’application devient utilisable.
- Utilisation de la mémoire : la consommation de ressources avec un contenu de navigateur et des fonctionnalités natives représentatifs.
- Utilisation du processeur : les performances pendant le rendu, la navigation et les opérations en arrière-plan.
- Taille de l’application : la taille du téléchargement et l’espace disque occupé après installation.
- Exigences de rendu : la nécessité de disposer de fenêtres ordinaires ou d’un rendu hors écran personnalisé.
Il est également important de distinguer CEF des frameworks reposant sur les vues web du système. CEF inclut Chromium au lieu de s’appuyer sur le moteur de navigateur installé par le système d’exploitation. Par conséquent, passer d’Electron à CEF ne produit pas automatiquement une application beaucoup plus légère.
Les développeurs dont la priorité est de réduire la taille des paquets applicatifs peuvent envisager des alternatives comme Tauri, qui utilise les vues web fournies par le système.
Ni Electron ni CEF ne devrait être considéré comme systématiquement plus rapide sans réaliser des tests de performance sur une implémentation réelle.
Sécurité et mises à jour du navigateur
Electron et CEF reposent tous deux sur l’architecture et les mécanismes de sécurité du navigateur Chromium, mais les développeurs sont responsables de la configuration appropriée de leurs applications.
Electron fournit des fonctionnalités telles que l’exécution des processus de rendu dans un bac à sable, l’isolation des contextes et la communication par IPC entre les fonctionnalités privilégiées de l’application et le contenu web. Sa documentation de sécurité recommande de restreindre l’accès à Node.js, de valider soigneusement les messages IPC et de considérer le contenu chargé à distance comme non fiable.
CEF prend également en charge l’architecture multiprocessus et les mécanismes d’isolation de sécurité de Chromium. Toutefois, puisque CEF est intégré dans une application contrôlée par son développeur, il revient à l’application hôte de déterminer quelles fonctionnalités du navigateur, autorisations et capacités natives doivent être exposées.
CEF prend en charge les liaisons JavaScript et la communication native, ce qui permet aux développeurs de relier le contenu web aux fonctionnalités de l’application. Ces interfaces doivent être conçues avec soin, en particulier lors de l’affichage de sites web tiers.
| Aspect de sécurité | Electron | CEF |
|---|---|---|
| Bac à sable Chromium | Pris en charge | Pris en charge |
| Accès natif privilégié | API Node.js et Electron | API natives de l’application hôte |
| Communication entre JavaScript et le code natif | Scripts de préchargement et IPC | Liaisons V8 et messagerie interprocessus |
| Isolation du contenu distant | Bac à sable des processus de rendu et isolation des contextes | Isolation des processus Chromium et contrôles de l’application hôte |
| Mises à jour de sécurité du navigateur | Mises à niveau d’Electron | Mises à niveau de CEF |
| Responsabilité de la sécurité de l’application | Développeur de l’application | Développeur de l’application |
La maintenance du navigateur est un autre élément important à prendre en compte. Electron et CEF distribuent généralement leur propre environnement d’exécution Chromium ; les développeurs doivent donc publier des mises à jour de l’application lorsque des correctifs de sécurité sont disponibles.
CEF propose des branches de publication qui suivent Chromium ainsi que des distributions binaires qui simplifient ce processus. De même, Electron maintient des versions intégrant les mises à jour de Chromium et de Node.js.
Aucune de ces approches ne supprime complètement le besoin d’une maintenance continue. Les applications qui utilisent d’anciennes versions de Chromium peuvent rester exposées à des vulnérabilités déjà corrigées en amont.
Pour les équipes qui développent des logiciels affichant des sites web quelconques, la maintenance de la sécurité doit être considérée comme une composante essentielle du cycle de vie de l’application, et non comme une tâche occasionnelle.
Adoption : grandes applications utilisant Electron et CEF
Electron et CEF sont tous deux largement adoptés en production, mais leurs modes d’utilisation diffèrent.
Electron est particulièrement présent dans les applications de bureau grand public dédiées à la productivité, à la communication et au développement. Microsoft utilise Electron pour Visual Studio Code, et parmi les autres produits Electron bien connus figurent Slack, Discord, Notion, Figma, Signal Desktop et GitHub Desktop.
CEF est également utilisé par de grandes entreprises du logiciel, en particulier pour intégrer des interfaces web dans des applications disposant d’une architecture native existante.
Voici quelques exemples :
| Application | Technologie | Utilisation typique |
|---|---|---|
| Visual Studio Code | Electron | Éditeur de code multiplateforme |
| Slack | Electron | Communication d’équipe |
| Discord | Electron | Plateforme de communication et de communautés |
| Notion | Electron | Prise de notes et productivité |
| Figma Desktop | Electron | Application de conception |
| Spotify Desktop | CEF | Interface reposant sur les technologies web dans le client de bureau |
| Steam | CEF | Interfaces web intégrées dans le client de bureau |
| OBS Studio | CEF | Sources de navigateur, superpositions et panneaux de navigateur ancrables |
Spotify est un utilisateur de CEF particulièrement bien documenté. Sa page officielle consacrée à l’open source publie les versions de CEF et de Chromium associées aux différentes versions de Spotify Desktop.
OBS Studio offre un autre exemple concret des raisons pour lesquelles les développeurs choisissent CEF. Son intégration obs-browser utilise CEF pour fournir des sources de navigateur, permettant aux utilisateurs d’afficher des superpositions web et d’autres contenus dans leurs scènes de streaming. CEF est un composant d’OBS Studio, et non le framework utilisé pour créer l’ensemble de l’application.
Steam utilise également des composants web intégrés basés sur Chromium dans son client de bureau, reliant ainsi des interfaces web à l’infrastructure plus large de son application native.
Ces exemples illustrent la distinction entre les deux technologies. Electron est souvent utilisé pour créer l’application de bureau complète, tandis que CEF sert fréquemment à introduire des fonctionnalités web dans des applications qui possèdent déjà d’importants composants natifs.
CEF ne doit pas être considéré comme une alternative obscure ou dépassée. Lancé en 2008, avant Electron, il est largement utilisé dans les logiciels commerciaux depuis de nombreuses années. Sa longue histoire et sa présence continue dans de grands produits montrent que l’intégration de Chromium reste une approche importante du développement d’applications de bureau.
Electron, quant à lui, a construit un écosystème particulièrement solide autour des applications de bureau basées sur JavaScript. Sa large adoption, ses outils éprouvés et la participation de grandes entreprises technologiques le rendent attractif pour les équipes qui créent de nouveaux produits à l’aide des technologies web.
Les deux frameworks présentent des atouts différents, car ils répondent à des exigences architecturales différentes.
Pourquoi nous avons choisi Electron chez WebCatalog
Chez WebCatalog, nous avons choisi Electron pour nos applications de bureau multiplateformes, car il 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 de manière indépendante et d’organiser leurs applications sous macOS, Windows et Linux. Notre logiciel doit prendre en charge des sites créés par des milliers de développeurs différents, avec des systèmes d’authentification, des mécanismes de stockage, des API de navigateur et des frameworks JavaScript variés.
Electron et CEF fournissent tous deux un environnement d’exécution Chromium cohérent, ce qui est important pour la compatibilité. Contrairement aux frameworks reposant sur les vues web du système, ils nous permettent d’utiliser une version connue de Chromium sur toutes les plateformes de bureau que nous prenons en charge.
Cependant, WebCatalog n’est pas avant tout une application native qui a besoin d’un composant de navigateur intégré. Les fonctionnalités du navigateur sont au cœur de notre produit. Nous avons besoin d’un contrôle poussé sur les fenêtres, les sessions, le stockage, les autorisations, la navigation et le comportement de l’application tout au long de son cycle de vie.
Electron fournit des API matures pour répondre à ces besoins. Ses interfaces BrowserWindow, webContents et session nous permettent de créer des fonctionnalités de type navigateur en JavaScript et TypeScript. Les partitions de session persistantes sont particulièrement importantes, car elles permettent aux utilisateurs de conserver des sessions de connexion indépendantes pour plusieurs comptes sur un même site web.
CEF fournit également des API pour gérer les instances de navigateur, les requêtes, le stockage et l’intégration native. En principe, beaucoup de ces fonctionnalités pourraient être implémentées avec CEF. Cela nous obligerait toutefois à développer et à maintenir nous-mêmes davantage d’infrastructure native.
L’intégration de Node.js dans Electron correspond également à notre pile technologique. Nous pouvons implémenter une grande partie de la logique de nos applications de bureau en TypeScript, partager du code entre nos produits et tirer parti de l’écosystème JavaScript.
Le développement multiplateforme est un autre facteur à prendre en compte. WebCatalog prend en charge macOS, Windows et Linux, notamment en matière de création de paquets applicatifs, d’intégrations et de comportements système propres à chaque plateforme. Les API éprouvées et les outils de distribution d’Electron réduisent la quantité de code natif que nous devons maintenir.
Nous reconnaissons qu’Electron entraîne un surcoût en ressources. L’inclusion de Chromium augmente la taille des applications, et les applications reposant sur un navigateur nécessitent une gestion rigoureuse des ressources. Plutôt que de remplacer Electron, nous nous sommes concentrés sur l’amélioration de notre utilisation de celui-ci.
Par exemple, nous avons introduit les clones APFS pour réduire l’espace disque occupé par les applications Mac générées, ce qui réduit le stockage redondant sans renoncer à la compatibilité de Chromium.
Notre décision ne signifie pas qu’Electron est universellement meilleur que CEF. Si WebCatalog était principalement une application native avec quelques interfaces web intégrées, CEF pourrait être un excellent choix. Mais comme notre produit repose fondamentalement sur les applications web et les fonctionnalités de navigateur, Electron offre une base plus productive et plus facile à maintenir.
Les domaines où CEF a l’avantage
Bien qu’Electron soit notre choix privilégié chez WebCatalog, CEF présente des avantages importants pour les applications qui nécessitent une intégration plus poussée avec des logiciels natifs.
CEF est particulièrement intéressant lorsque les développeurs disposent déjà d’une application C++ bien établie et souhaitent introduire des interfaces web modernes sans remplacer leur architecture existante.
Sa prise en charge du rendu hors écran constitue un autre avantage majeur. Les logiciels de streaming et les moteurs de jeux, par exemple, peuvent avoir besoin d’effectuer le rendu du contenu web directement dans des pipelines graphiques personnalisés plutôt que dans des fenêtres de bureau classiques. CEF fournit des API éprouvées pour ces cas d’usage.
CEF donne également aux développeurs un contrôle important sur l’intégration du navigateur. Ils peuvent personnaliser le traitement des requêtes, la navigation, les liaisons JavaScript, le chargement des ressources et la manière dont les instances de navigateur interagissent avec les composants natifs de l’application.
Pour les équipes qui possèdent une solide expertise en développement natif, cette souplesse peut l’emporter sur la commodité d’Electron.
CEF mérite d’être envisagé dans les cas suivants :
- Ajouter des interfaces web à une application native existante. Les développeurs peuvent conserver l’architecture actuelle de leur application et intégrer Chromium là où cela est nécessaire.
- Créer un logiciel ayant des exigences de rendu personnalisées. Le rendu hors écran permet d’intégrer le contenu web dans des pipelines graphiques et des interfaces spécialisées.
- Assurer une intégration poussée avec des fonctionnalités natives en C++. CEF expose des API natives et permet un contrôle détaillé du comportement du navigateur.
- Maintenir une application CEF établie. Migrer vers Electron peut entraîner des changements architecturaux importants sans apporter de bénéfices significatifs.
- Combiner des interfaces natives et web. Les développeurs peuvent utiliser Chromium pour certaines parties d’une application tout en conservant ailleurs des composants d’interface natifs.
CEF implique toutefois davantage de responsabilités concernant l’infrastructure de l’application. Les développeurs peuvent devoir mettre en place leurs propres mécanismes de création de paquets, de mise à jour, de gestion des fenêtres et d’intégration propres à chaque plateforme.
Pour les équipes déjà outillées pour maintenir des applications natives, cela peut être tout à fait raisonnable. Pour les équipes spécialisées dans le web qui créent un nouveau produit de bureau, cela peut introduire une complexité inutile.
Electron ou CEF : lequel choisir ?
Les deux technologies sont matures, activement développées et capables de prendre en charge des logiciels de bureau sophistiqués. Le meilleur choix dépend principalement de votre objectif : créer une nouvelle application de bureau autour des technologies web ou intégrer des fonctionnalités web dans une application native existante.
| Votre priorité | Meilleur point de départ | Pourquoi |
|---|---|---|
| Nouvelle application de bureau en JavaScript ou TypeScript | Electron | Framework d’application complet |
| Application native C++ existante | CEF | S’intègre dans l’architecture native |
| Développement natif minimal | Electron | API Node.js et JavaScript |
| Intégration de contenu web dans des fenêtres natives | CEF | Conçu spécifiquement pour l’intégration |
| Rendu hors écran et pipelines graphiques personnalisés | CEF | API de rendu dédiées |
| Outils complets de création de paquets et de mise à jour des applications de bureau | Electron | Écosystème de distribution éprouvé |
| Intégration directe avec du code natif C++ | CEF | Interfaces natives C et C++ |
| Version de Chromium cohérente sur les différentes plateformes de bureau | L’un ou l’autre | Tous deux incluent Chromium |
| Gestion complexe des sessions de navigateur | L’un ou l’autre | Tous deux offrent des fonctionnalités de gestion du navigateur |
| Paquets applicatifs de petite taille | Aucun n’a d’avantage intrinsèque | Tous deux distribuent Chromium |
| Équipe de développement JavaScript existante | Electron | Pile de développement familière |
| Produit existant basé sur CEF | CEF | Évite une migration inutile |
Pour la plupart des développeurs web qui commencent une nouvelle application de bureau multiplateforme, Electron est généralement le choix le plus pratique. Il fournit l’architecture de l’application, les intégrations natives, les outils de développement et l’écosystème de distribution nécessaires pour créer un produit complet sans tout développer à partir de zéro.
CEF est souvent la meilleure option pour les développeurs qui possèdent déjà une application native ou qui ont besoin de fonctionnalités spécialisées d’intégration de navigateur. Sa souplesse et son intégration native directe le rendent particulièrement utile pour les moteurs de jeux, les outils de streaming, les applications industrielles et les produits natifs complexes comportant des interfaces web intégrées.
Aucune des deux technologies n’est intrinsèquement plus rapide ou plus sûre. Ces caractéristiques dépendent fortement de l’application, de son architecture et de la qualité de sa mise en œuvre.
Conclusion
Electron et Chromium Embedded Framework partagent la même technologie de navigateur sous-jacente, mais ils résolvent des problèmes différents.
Electron est conçu pour rendre le développement d’applications de bureau accessible aux développeurs web. Il combine Chromium, Node.js et des API natives de bureau dans un framework qui permet aux équipes de créer des applications sophistiquées en JavaScript et TypeScript.
CEF est conçu pour intégrer Chromium dans d’autres applications. Il offre un contrôle de plus bas niveau sur l’intégration du navigateur et se révèle particulièrement précieux pour les applications natives qui ont besoin d’interfaces web ou de capacités de rendu spécialisées.
Tous deux ont démontré leur valeur dans des logiciels majeurs en production. Electron fait fonctionner des applications comme Visual Studio Code, Slack, Discord et Notion, tandis que CEF est utilisé dans des produits tels que Spotify, Steam et OBS Studio.
Chez WebCatalog, nous avons choisi Electron parce que nos produits reposent fondamentalement sur les fonctionnalités du navigateur. Son environnement d’exécution Chromium cohérent, ses API matures de gestion du navigateur et son écosystème JavaScript nous permettent de développer et de maintenir efficacement des applications de bureau multiplateformes.
CEF reste un excellent choix pour les développeurs qui travaillent sur des applications natives, en particulier lorsque Chromium doit être intégré à une architecture existante plutôt que servir de fondation à l’ensemble du produit.
La décision dépend en définitive de ce que vous construisez. Si vous souhaitez créer une application de bureau complète avec des technologies web, Electron constitue généralement le meilleur point de départ. Si vous souhaitez ajouter Chromium à une application native, CEF est probablement l’outil le plus adapté.
