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 sur macOS, Windows et Linux. Elles répondent toutefois à des objectifs 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 à des applications existantes ou nouvelles, généralement écrites en C++ ou dans d’autres langages natifs.
Ces 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 leurs différences, et dans quels cas est-il judicieux de privilégier 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 qu’ils offrent et les applications auxquelles ils sont destinés.
| Caractéristique | Electron | Chromium Embedded Framework (CEF) |
|---|---|---|
| Première apparition | 2013 | 2008 |
| Objectif principal | Créer des applications de bureau complètes | Intégrer Chromium à 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 au moyen de solutions personnalisées | Prise en charge intégrée dans les API |
| Taille de l’application | Généralement importante | Dépend de l’intégration, mais Chromium est volumineux |
| 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 |
| Particulièrement adapté à | Applications de bureau basées sur JavaScript | Applications natives nécessitant du contenu web intégré |
La distinction la plus importante 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 directement interchangeables, car ils opèrent à 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é. 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 la majeure partie 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 de navigation, prendre en charge les menus, afficher des notifications, accéder aux boîtes de dialogue système et s’intégrer au 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 à 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 influe sur la façon 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 est habituellement un composant au sein d’une application plus vaste.
CEF peut également servir à créer des applications dont les interfaces reposent principalement sur des technologies web, mais les développeurs doivent alors mettre en œuvre eux-mêmes une plus grande partie de l’infrastructure applicative qui les entoure.
Détail historique intéressant : les premières versions d’Electron et de NW.js utilisaient CEF. Electron a finalement opté pour une intégration plus directe avec Chromium, car l’abstraction de CEF rendait certaines fonctionnalités difficiles à implémenter, en particulier 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 utiliser 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 d’Electron avec Node.js 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 telles que React, Vue, Svelte et Angular peuvent être utilisées sans changements architecturaux majeurs.
CEF est principalement conçu autour d’API C et C++. Bien qu’il existe des liaisons tierces pour des langages comme C#, Java, Python et Delphi, les développeurs doivent toujours 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 constituer 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 configuration et de travail d’intégration native.
La différence s’étend aussi aux outils. Electron bénéficie d’outils éprouvés comme 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 à leurs propres systèmes de compilation et de déploiement.
Cela ne signifie pas que CEF est moins performant sur le plan fonctionnel. Cela reflète simplement son rôle de composant intégrable, plutôt que de plateforme complète de développement d’applications.
Performances, consommation de 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 lié à 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 façon 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 utiliser Chromium uniquement pour les 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 pourrait utiliser CEF pour un panneau de paramètres ou une interface web intégrée, tout en conservant en code natif son moteur de rendu, le traitement des documents et les autres fonctionnalités sensibles aux performances.
Les applications Electron peuvent également exécuter du code natif par l’intermédiaire d’extensions Node.js, de processus externes ou de modules natifs. Toutefois, l’architecture d’Electron est généralement orientée vers la construction de l’application elle-même à l’aide des technologies web.
Le rendu hors écran est une fonctionnalité particulièrement utile de CEF. Plutôt que d’afficher du contenu web dans une fenêtre de navigateur traditionnelle, CEF peut effectuer le rendu dans des tampons que l’application hôte traite et affiche elle-même. Cela s’avère précieux pour des applications comme les moteurs de jeu, les logiciels de diffusion en direct et les outils dotés de systèmes de rendu personnalisés.
Electron peut prendre en charge des flux de rendu spécialisés grâce à des intégrations supplémentaires, mais CEF propose le rendu hors écran comme une composante é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 : le délai nécessaire pour que l’application devienne utilisable.
- Utilisation de la mémoire : la consommation de ressources avec du 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 fenêtres ordinaires ou d’un rendu hors écran personnalisé.
Il est également important de distinguer CEF des frameworks reposant sur les webviews 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 solutions comme Tauri, qui utilise les webviews fournies par le système.
Ni Electron ni CEF ne doit ê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 il appartient aux développeurs de configurer correctement leurs applications.
Electron propose des fonctionnalités comme le placement des processus de rendu dans un bac à sable, l’isolation des contextes et les communications 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 l’isolation de sécurité de Chromium. Toutefois, puisque CEF est intégré à une application contrôlée par son développeur, l’application hôte doit décider quelles fonctionnalités du navigateur, autorisations et capacités natives doivent être exposées.
CEF prend en charge les liaisons JavaScript et les communications natives, 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 de JavaScript vers le code natif | Scripts de préchargement et IPC | Liaisons V8 et messagerie entre processus |
| 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 aspect important. Electron et CEF distribuent généralement leur propre environnement d’exécution Chromium ; les développeurs doivent donc publier des mises à jour de leurs applications lorsque des correctifs de sécurité sont disponibles.
CEF fournit des branches de publication qui suivent Chromium et 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 entièrement la nécessité d’une maintenance continue. Les applications utilisant d’anciennes versions de Chromium peuvent rester exposées à des vulnérabilités déjà corrigées en amont.
Pour les équipes qui créent 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 : les grandes applications utilisant Electron et CEF
Electron et CEF sont tous deux largement utilisés en production, mais leurs modes d’utilisation diffèrent.
Electron est particulièrement présent parmi les applications de bureau grand public de productivité, de communication et de développement. Microsoft utilise Electron pour Visual Studio Code, tandis que Slack, Discord, Notion, Figma, Signal Desktop et GitHub Desktop figurent parmi les autres produits Electron bien connus.
CEF est également utilisé par de grands éditeurs de logiciels, en particulier pour intégrer des interfaces web à des applications disposant déjà d’une architecture native.
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 le web au sein du client de bureau |
| Steam | CEF | Interfaces web intégrées au client de bureau |
| OBS Studio | CEF | Sources de navigateur, superpositions et panneaux de navigateur |
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 versions de Spotify Desktop.
OBS Studio fournit un autre exemple clair des raisons qui poussent les développeurs à choisir CEF. Son intégration obs-browser utilise CEF pour fournir des sources de navigateur, ce qui permet aux utilisateurs d’afficher des superpositions web et d’autres contenus dans les scènes de diffusion en direct. CEF est un composant d’OBS Studio, et non le framework utilisé pour construire l’ensemble de l’application.
Steam utilise également des composants web intégrés reposant sur Chromium dans son client de bureau, en intégrant des interfaces web à son infrastructure applicative native plus large.
Ces exemples illustrent la distinction entre les deux technologies. Electron est souvent utilisé pour créer l’intégralité d’une application de bureau, tandis que CEF sert fréquemment à ajouter des fonctionnalités web à des applications possédant déjà d’importants composants natifs.
CEF ne doit pas être considéré comme une solution obscure ou dépassée. Créé en 2008, avant Electron, il est largement utilisé dans les logiciels commerciaux depuis de nombreuses années. Sa longue histoire et son utilisation continue dans des produits majeurs montrent que l’intégration de Chromium reste une approche importante du développement d’applications de bureau.
De son côté, Electron a bâti 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 en font une solution attrayante pour les équipes qui créent de nouveaux produits avec les technologies web.
Les deux frameworks possèdent des atouts différents parce qu’ils répondent à des exigences architecturales différentes.
Pourquoi nous choisissons Electron chez WebCatalog
Chez WebCatalog, nous avons choisi Electron pour faire fonctionner 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 sur macOS, Windows et Linux. Notre logiciel doit prendre en charge des sites web 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 basés sur les webviews du système, ils nous permettent d’utiliser une version connue de Chromium sur toutes les plateformes de bureau que nous prenons en charge.
Toutefois, 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 étendu sur les fenêtres, les sessions, le stockage, les autorisations, la navigation et le comportement du cycle de vie de l’application.
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, bon nombre de ces mêmes fonctionnalités pourraient être implémentées avec CEF. Cela nous obligerait toutefois à construire et à maintenir nous-mêmes davantage d’infrastructure native.
L’intégration d’Electron avec Node.js 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 les 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, y compris la création de paquets applicatifs, les intégrations et les 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. L’inclusion de Chromium augmente la taille des applications, et les applications basées 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 cet outil.
Par exemple, nous avons introduit des clones APFS pour réduire l’espace disque utilisé 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 constituer un excellent choix. Mais comme notre produit repose fondamentalement sur les applications web et les fonctionnalités de navigateur, Electron fournit 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 notable. Des applications comme les logiciels de diffusion en direct et les moteurs de jeu 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’utilisation.
CEF offre également aux développeurs un contrôle considérable 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 façon dont les instances de navigateur interagissent avec les composants natifs de l’application.
Pour les équipes disposant d’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 leur architecture applicative actuelle et intégrer Chromium là où ils en ont besoin.
- Créer des logiciels ayant des exigences de rendu spécifiques. Le rendu hors écran permet d’intégrer du contenu web à des pipelines graphiques et à des interfaces spécialisées.
- Réaliser 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.
- Assurer la maintenance d’une application CEF existante. Une migration vers Electron peut entraîner des changements architecturaux importants sans apporter d’avantages significatifs.
- Combiner des interfaces natives et web. Les développeurs peuvent utiliser Chromium pour certaines parties d’une application tout en conservant des composants d’interface natifs ailleurs.
CEF implique toutefois davantage de responsabilités en matière d’infrastructure applicative. Les développeurs peuvent devoir mettre en œuvre 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à équipées pour assurer la maintenance d’applications natives, cela peut être tout à fait raisonnable. Pour les équipes orientées 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 à une application native existante.
| Votre priorité | Meilleur point de départ | Pourquoi |
|---|---|---|
| Nouvelle application de bureau utilisant JavaScript ou TypeScript | Electron | Framework d’application complet |
| Application native C++ existante | CEF | S’intègre à 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 pour le bureau | Electron | Écosystème de distribution éprouvé |
| Intégration directe avec du code natif C++ | CEF | Interfaces natives C et C++ |
| Cohérence de Chromium entre les plateformes de bureau | Les deux | Tous deux incluent Chromium |
| Gestion complexe des sessions de navigateur | Les deux | Tous deux fournissent des fonctions de gestion du navigateur |
| Paquets applicatifs de petite taille | Aucun avantage intrinsèque pour l’un ou l’autre | 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 démarrent une nouvelle application de bureau multiplateforme, Electron est généralement le choix le plus pratique. Il fournit l’architecture applicative, 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 disposent déjà d’une application native ou qui ont besoin de fonctions spécialisées d’intégration de navigateur. Sa souplesse et son intégration native directe le rendent particulièrement utile pour des logiciels comme les moteurs de jeu, les outils de diffusion en direct, les applications industrielles et les produits natifs complexes dotés d’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 son implémentation.
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 à d’autres applications. Il offre un contrôle de plus bas niveau sur l’intégration du navigateur et s’avère particulièrement précieux pour les applications natives qui ont besoin d’interfaces web ou de fonctions de rendu spécialisées.
Tous deux ont démontré leur valeur dans des logiciels majeurs utilisés 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.
En fin de compte, la décision dépend de ce que vous construisez. Si vous souhaitez créer une application de bureau complète à l’aide des technologies web, Electron est généralement le meilleur point de départ. Si vous souhaitez ajouter Chromium à une application native, CEF est probablement l’outil le plus approprié.
