Au cours des dernières semaines, nous avons reçu plusieurs questions sur les différences entre la nouvelle WebView2 et Electron.

Les deux équipes ont pour but de transposer la technologie du web pour les application de Bureau de la meilleure façon possible et une comparaison faite en commun est en cours de discussion.

Electron et WebView2 sont des projets en évolution rapide et constante. Nous avons rassemblé un bref aperçu des similitudes et des différences entre Electron et WebView2 telles qu’elles existent aujourd’hui.

---

Vue d’ensemble de l’architecture​

Electron et WebView2 sont tous deux issus des source de Chromium pour le rendu du contenu Web. À proprement parler, WebView2 est généré à partir des sources de Edge, mais Edge est construit à l’aide d’un fork de Chromium. Electron ne partage aucune DLL avec Chrome. Les fichiers binaires WebView2 sont liés fortement à Edge (canal stable à compter d’Edge 90), et partagent certains éléments. Voir le mode de distribution Evergreen pour plus d'informations.

Les applications Electron regroupent et distribuent toujours la version exacte d’Electron avec laquelle elles ont été développées. WebView2 a deux options pour la distribution. Vous pouvez soit empaqueter la même bibliothèque WebView2 utilisée pour le développement de votre application, soit utiliser une version partagée du runtime pouvant être déjà présente sur le système. WebView2 fournit des outils pour chaque approche, y compris un programme d’installation d’amorçage au cas où le runtime partagé serait manquant. WebView2 est inclus dans Windows 11.

Les applications qui incluent des frameworks sont responsables de leur mise à jour et ce même pour les versions mineures de sécurité. Pour les applications utilisant le runtime partagé WebView2, WebView2 possède son propre programme de mise à jour, similaire à Chrome ou Edge, qui s’exécute indépendamment de votre application. La mise à jour du code de l’application ou de l’une de ses dépendances est toujours une responsabilité du développeur, comme avec Electron. Electron et WebView2 ne sont pas gérés par Windows Update.

Electron et WebView2 héritent tous deux de l’architecture multi-processus de Chromium - à savoir, un processus principal unique qui communique avec un ou plusieurs processus de rendu. Ces processus sont entièrement séparés des autres applications exécutées sur le système. Chaque application Electron est une arborescence de processus séparée qui contient un processus de navigation racine, des processus utilitaires et éventuellement d'autres processus de rendu. Les applications WebView2 qui utilisent le même dossier de données utilisateur (comme le ferait une suite d’applications), partagent les processus qui ne concernent pas le rendu. Les applications WebView2 utilisant différents dossiers de données ne partagent pas de processus.

• Modèle des processus d'Electron:

  

• Modèle de processus des applications basées sur WebView2 :

  

Pour en savoir plus sur le modèle de processus de WebView2, et sur le modèle de processus d' Electron, cliquez ici.

Electron fournit des API pour les besoins courants des applications de bureau telles que les menus, l'accès au système de fichiers, les notifications et plus encore. WebView2 est un composant destiné à être intégré dans un framework d'application tel que WinForms, WPF, WinUI ou Win32. WebView2 ne fournit pas d'API vers le système d'exploitation en dehors de la norme web via JavaScript.

Node.js est intégré dans Electron. Les applications Electron peuvent utiliser n'importe quelle API Node.js, module ou node-native-addon depuis le moteur de rendu et les processus principaux. Une application WebView2 ne suppose pas dans quel langage ou infrastructure le reste de votre application est écrit. Votre code JavaScript doit transmettre par proxy tout accès au système d’exploitation via le processus application-hôte.

Electron s'efforce de maintenir la compatibilité avec l'API web, y compris les API développées à partir du Projet Fugu. Nous avons un aperçu de la compatibilité de l’API Fugu d’Electron. WebView2 maintient une liste similaire de différences d'API par rapport à Edge.

Electron a un modèle de sécurité configurable pour le contenu web, qui va de l'accès complet au bac à sable. Le contenu WebView2 est toujours en bac à sable. Electron a une documentation de sécurité complète sur le choix de votre modèle de sécurité. WebView2 dispose également des : bonnes pratiques de sécurité.

Les sources d'Electron sont maintenues et disponibles sur GitHub. Les applications peuvent modifier et leurs propres version d'Electron. Les sources de WebView2 ne sont pas disponibles sur GitHub.

Résumé rapide:

	Electron	WebView2
Installation des dépendances	Chromium	Edge
Source disponible sur GitHub	Oui	Non
Partage des DLL Edge/Chrome	Non	Oui (à compter de Edge 90)
Runtime partagé entre applications	Non	Facultatif
API d’application	Oui	Non
Node.js	Oui	Non
Mode bac à sable	Facultatif	Toujours
Nécessite un Framework d'application	Non	Oui
Plateformes supportées	Mac, Win, Linux	Win (Mac/Linux prévu)
Partage de processus entre applications	Jamais	Facultatif
Mises à jour du framework gérées par	Application	WebView2

Discussion sur les performances​

En ce qui concerne le rendu de votre contenu web, nous nous attendons à peu de différence de performance entre Electron, WebView2 et tout autre moteur de rendu basé sur Chromium. Nous avons créé ossatures d'applications construites à l'aide d'Electron, C++ + WebView2, et C# + WebView2 pour les personnes intéressées à étudier les différences potentielles de performance.

Il y a quelques différences qui entrent en jeu en dehors du rendu de contenu web, et les gens d'Electron, WebView2, Edge, et d'autres personnes ont exprimé leur intérêt à travailler sur une comparaison détaillée, y compris les PWAs.

La communication inter-processus(IPC)​

Nous voulons mettre en évidence immédiatement une différence , car nous pensons qu'il s'agit souvent d'une considération de performance dans les applications Electron.

Dans Chromium, le processus du navigateur agit comme un courtier d'IPC entre les moteurs de rendu en bac à sable et le reste du système. Tandis qu'Electron autorise les processus de rendu sans bac à sable (sandbox), de nombreuses applications choisissent d'activer le sandbox pour plus de sécurité. WebView2 a toujours le sandbox activé, donc pour la plupart des applications Electron et WebView2 les IPC peuvent affecter les performances globales.

Même si Electron et WebView2 ont des modèles de processus similaires, les IPC sous-jacents diffèrent. La communication entre JavaScript et C++ ou C# nécessite du marshalling, le plus souvent vers une chaîne JSON. La sérialisation/parsing JSON est une opération coûteuse, et les goulots d’étranglement IPC peuvent avoir un impact négatif sur les performances. À partir de Edge 93, WV2 utilisera CBOR pour les événements du réseau.

Electron prend en charge les IPC directement entre deux processus via l'API MessagePorts , qui utilise l'algorithme de clonage structuré. Les applications qui tirent parti de cela peuvent éviter de payer le tribut de la sérialisation JSON lors de l'envoi d'objets entre processus.

Récapitulatif​

Electron et WebView2 ont un certain nombre de différences, mais ne vous attendez pas à une grande différence par rapport à la façon dont ils effectuent le rendu du contenu web. En définitive, l'architecture d'une application et ses bibliothèques/ frameworks JavaScript ont un impact plus important sur la mémoire et les performances que tout autre chose car de toute façon Chromium est Chromium peu importe où il fonctionne.

Remerciements spéciaux à l'équipe WebView2 pour avoir examiné ce post, et s'assurer que nous avons une vue actualisée de l'architecture WebView2. Ils seront heureux de recevoir tout commentaire sur le projet.

A partir de Septembre 2021, Electron publiera une nouvelle version majeure et stable toutes les 8 semaines.

---

En 2019, Electron est passé à un cycle d'une publication toute les 12 semaines pour correspondre au cycle de publication de 6 semaines de Chromium. Récemment, Chrome et Microsoft ont annoncé des changements qui nous ont fait reconsidérer la cadence actuelle des versions d'Electron:

1. Chromium prévoit de publier une release toutes les 4 semaines et ce à partir de Chrome 94 le 21 septembre 2021. Cette cadence de version ajoute également une nouvelle option Extended Stable toutes les 8 semaines, qui contiendra toutes les corrections de sécurité mises à jour.

2. Le Microsoft Store nécessitera que les applications basées sur Chrome ne soient pas plus anciennes que de 2 versions majeures. Par exemple, si la dernière version majeure de Chromium est 85, tout navigateur basé sur Chromium doit être au moins sur Chromium version 83 ou supérieure. Cette règle inclut les applications Electron.

À partir de septembre 2021, Electron sortira une nouvelle version stable majeure toutes les 8 semaines, pour correspondre aux 8 semaines des versions stables de Chromium.

Notre première version avec Chromium Extended Stable sera Electron 15 le 21 septembre 2021.

Sachant que le changement de cadence de publication aura un impact sur d'autres applications en aval, nous voulions le faire savoir à notre communauté de développeurs le plus tôt possible. Pour en savoir plus, voyez notre calendrier de publication 2021.

Electron 15: Alpha Temporaire​

Given that our original Electron 15 release targeted a non-Extended Stable version (Chromium's Extended Stable versions are based on their even-numbered versions), we needed to change our original target release date. However, an Electron app must use the most recent 2 major versions of Chromium to be accepted to the Microsoft Store, which made waiting for two Chromium versions untenable.

With these two requirements, our team faced a timing dilemma. Moving Electron 15 to include Chromium M94 would allow app developers to get on the very first Extended Stable version of Chromium; however, it would also shorten the beta-to-stable cycle to only 3 weeks.

To help with this switchover, Electron will offer a temporary alpha build, only for the Electron 15 release. This alpha build will allow developers more time to test and plan for an Electron 15 release, with a more stable build than our current nightlies.

The alpha channel build will ship for Electron 15 on July 20th, 2021. It will transition to a beta release on September 1st, 2021 with a stable release target of September 21st, 2021. Subsequent Electron releases will not have alpha releases.

Plan de diffusion pour 2021​

Voici notre calendrier de publication pour 2021 :

Electron	Chrome	Versions alpha	Versions bêta	Version stable	Cycle stable (n° de semaine)
E13	M91	-	05-Mars-2021	25-Mai-2021	12
E14	M93	-	26-Mai-2021	31-Août-2021	14
E15	M94	20-Juil-2021	01-Sept-2021	21-Sept-2021	9 (comprend la version alpha)
E16	M96	-	22-Sept-2021	16-Nov-2021	8
E17	M98	-	17-Nov-2021	01-Fev-2022	11

Adding the alpha channel extends the development time before Electron 15's launch from 3 weeks to 9 weeks - closer to our new 8 week cycle, while still meeting the requirements for Windows Store submission.

To further help app developers, for the remainder of 2021 until May 2022, we will also be extending our supported versions policy from the latest 3 versions to the latest 4 versions of Electron. That means that even if you can't immediately alter your upgrade schedule, older versions of Electron will still receive security updates and fixes.

Tenir compte des préoccupations​

Il y a une raison pour laquelle nous publions ce post bien avant que ce changement de cycle de publication ne soit prévu. Nous savons qu’un cycle de sortie plus rapide aura un impact réel sur les applications Electron - et certaines peuvent déjà amener à considérer notre cadence de sortie majeure agressive.

Nous avons tenté de répondre aux préoccupations communes ci-dessous :

❓ Pourquoi même faire ce changement ? Pourquoi ne pas garder la cadence de la sortie de 12 semaines ?​

To deliver the most up-to-date versions of Chromium in Electron, our schedule needs to track theirs. More information around Chromium's release cycle can be found here.

Additionally, the current 12 week release cadence would be untenable with the Microsoft Store's new submission requirements. Even apps on the latest stable version of Electron would experience a roughly two week period where their app may be rejected under the new security requirements.

Every new Chromium release contains new features, bug fixes / security fixes, and V8 improvements. We want you, as app developers, to have these changes in a timely manner, so our stable release dates will continue to match every other Chromium stable release. As an app developer, you'll have access to new Chromium and V8 features and fixes sooner than before.

❓ Le calendrier de sortie des 12 semaines existantes se déplace déjà rapidement. Quelles mesures l'équipe prend-elle pour faciliter la mise à niveau ?​

One advantage of more frequent releases is having smaller releases. We understand that upgrading Electron's major versions can be difficult. We hope that smaller releases will introduce fewer major Chromium and Node changes, as well as fewer breaking changes, per release.

❓ Y aura-t-il une version alpha disponible pour les futures versions d'Electron ?​

There are no plans to support a permanent alpha release at this time. This alpha is only intended for Electron 15, as a way to help developers upgrade more easily in the shortened release period.

❓ Electron va-t-il étendre le nombre de versions supportées ?​

We will be extending our supported version policy from the latest three versions to the latest four versions of Electron until May 2022, with the release of Electron 19. After Electron 19 is released, we'll return to supporting the latest three major versions, as well as the beta and nightly releases.

E13 (Mai 21)	E14 (Aoû'21)	E15 (Sep'21)	E16 (Nov'21)	E17 (Fév'23)	E18 (Mar'22)	E19 (Mai'22)
13.x.y	14.x.y	15.x.y	16.x.y	17.x.y	18.x.y	19.x.y
12.x.y	13.x.y	14.x.y	15.x.y	16.x.y	17.x.y	18.x.y
11.x.y	12.x.y	13.x.y	14.x.y	15.x.y	16.x.y	17.x.y
--	--	12.x.y	13.x.y	14.x.y	15.x.y	--

Questions?​

📨 Si vous avez des questions ou des préoccupations, veuillez nous écrire à info@electronjs.org ou rejoindre notre Discord. Nous savons qu'il s'agit d'un changement qui aura un impact sur de nombreuses applications et développeurs, et vos commentaires sont très importants pour nous. Nous voulons avoir de vos nouvelles !

Electron 13.0.0 est disponible ! Cette version inclue les mises à jour pour Chromium 91, V8 9.1, et Node. js. Nous avons ajouté plusieurs mises à jour de l'API, des corrections de bugs et des améliorations générales. Lisez la suite ci-dessous pour plus de détails !

---

La team Electron est excitée d'annoncer la sortie de Electron 13.0.0 ! Vous pouvez l'installer via npm install electron@latest ou le télécharger depuis notre site officiel. Continuez de lire pour plus de détails sur cette version, et s'il vous plaît, partagez vos commentaires et remarques !

Changements notables​

Changements de la Stack​

• Chromium 91
  • Nouveau avec Chrome 91
  • Nouveau avec Chrome 90
• Node.js 14.16.0
  • Article de blog sur Node 14.16.0
  • Article de blog sur Node 14.0.0
• V8 9.1
  • Article de blog sur V8 9.1
  • Article de blog sur V8 9.0

Nouveautés de cette version​

• Ajout de la propriété process.contextIsolated qui indique si le contexte de rendu actuel a contextIsolation activé. #28252
• Ajout de la nouvelle API session.storagePath pour obtenir le chemin des données spécifiques à la session sur le disque. #28866
• Déprécié l'événement new-window de WebContents. Il est remplacé par webContents.setWindowOpenHandler()
• Ajout de process.contextId utilisé par @electron/remote. #28251

Voir les notes de version 13.0.0 pour une liste complète des nouvelles fonctionnalités et des modifications.

Changements majeurs avec rupture de compatibilité​

• window.open() le paramètre frameName n'est plus défini comme titre de fenêtre. #27481
• session.setPermissionCheckHandler(handler) a été modifié pour permettre au premier paramètre de handler, webContents d'être null. #19903

Vous trouverez plus d’informations sur ces changements et les changements futurs sur la pagechangements de rupture prévus.

Changements d'API​

• Ajout de l'option roundedCorners pour BrowserWindow. #27572
• Ajout de la nouvelle API session.storagePath pour obtenir le chemin des données spécifiques à la session sur le disque.28866
• Ajout de la prise en charge du passage d'éléments DOM par le pont contextuel. #26776
• Ajout de process.uptime() aux moteurs de rendu en bac à sable. #26684
• Ajout de champs manquants aux paramètres émis dans le cadre de l'événement context-menu.#26788
• Ajout de la prise en charge de l'enregistrement des service workers de l'extension Manifest V3.
• Ajout de l’événement « registration-completed » aux ServiceWorkers. #27562

Modifications: éléments supprimés et dépréciés​

Les API suivantes ont été supprimées ou sont désormais dépréciées :

• Déprécié l'événement new-window de WebContents. Il est remplacé par webContents.setWindowOpenHandler()

• Suppression de shell.moveItemToTrash() qui était déprécié. #26723

• Suppression des API d'extension BrowserWindow dépréciées suivantes: :

  • BrowserWindow.addExtension(path)
  • BrowserWindow.addDevToolsExtension(path)
  • BrowserWindow.removeExtension(name)
  • BrowserWindow.removeDevToolsExtension(name)
  • BrowserWindow.getExtensions()
  • BrowserWindow.getDevToolsExtensions()

  Utiliser l'API session à la place :

  • chemin ses.loadExtension(path)
  • ses.removeExtension(extension_id)
  • ses.getAllExtensions()

• Les méthodes suivantes de systemPreferences ont été dépréciées :

  • systemPreferences.isDarkMode()
  • systemPreferences.isInvertedColorScheme()
  • systemPreferences.isHighContrastColorScheme()

  Veuillez utiliser à la place les propriétés de nativeTheme suivantes :

  • nativeTheme.shouldUseDarkColors
  • nativeTheme.shouldUseInvertedColorScheme
  • nativeTheme.shouldUseHighContrastColors

Fin du support pour 10.x.y​

Electron 10.x.y a atteint sa limite pour le support conformément à la politique d'assistance du projetpolitique d'assistance. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8. Bien que nous veillions à ne pas faire de promesses à propos des dates de publication, notre plan est la sortie de nouvelles versions majeures d'Electron avec de nouvelles versions de ces composants environ un trimestre. Le planning escompté de la version 14.0.0 planning défini les dates clés du cycle de vie de développement d'Electron 14.0. Aussi, regardez notre document de versioning pour plus d'informations sur le versioning dans Electron.

Pour des informations sur les changements de rupture prévus dans les versions à venir d'Electron, regardez notre documentation sur les changements de rupture planifiés.

Electron 12.0.0 est disponible ! It includes upgrades to Chromium 89, V8 8.9 and Node.js 14.16. We've added changes to the remote module, new defaults for contextIsolation, a new webFrameMain API, and general improvements. Lisez la suite ci-dessous pour plus de détails !

---

La team Electron est excitée d'annoncer la sortie de Electron 12.0.0 ! Vous pouvez l'installer via npm install electron@latest ou le télécharger depuis notre site officiel. Continuez de lire pour plus de détails sur cette version, et s'il vous plaît, partagez vos commentaires et remarques !

Changements notables​

Changements de la Stack​

• Chromium 89
  • Nouveau avec Chrome 88
  • Nouveau avec Chrome 89
• Node.js 14.16
  • Article de blog sur Node 14.16.0
  • Article de blog sur Node 14.0.0
• V8 8.9
  • Article de blog sur V8 8.8
  • Article de blog sur V8 8.9

Nouveautés de cette version​

• The ContextBridge exposeInMainWorld method can now expose non-object APIs. #26834
• Upgraded from Node 12 to Node 14. #23249
• Added a new webFrameMain API for accessing sub-frames of a WebContents instance from the main process. #25464
• The default values of contextIsolation and worldSafeExecuteJavaScript are now true. #27949 #27502

Voir les notes de version 12.0.0 pour une liste complète des nouvelles fonctionnalités et des modifications.

Changements majeurs avec rupture de compatibilité​

• Déprécié le module remote. It is replaced by @electron/remote. #25293
  • If you are currently using the remote module, we've written a guide to migrating to @electron/remote here.
• Changed the default value of contextIsolation to true. #27949
• Changed the default value of worldSafeExecuteJavaScript to true. #27502
• Changed the default of crashReporter.start({ compress }) from false to true. #25288
• Removed Flash support: Chromium has removed support for Flash, which was also removed in Electron 12. See Chromium's Flash Roadmap for more details.
• Required SSE3 for Chrome on x86: Chromium has removed support for older x86 CPUs that do not meet a minimum of SSE3 (Streaming SIMD Extensions 3) support. This support was also removed in Electron 12.

Vous trouverez plus d’informations sur ces changements et les changements futurs sur la pagechangements de rupture prévus.

Changements d'API​

• Added webFrameMain API: The webFrameMain module can be used to look up frames across existing WebContents instances. This is the main process equivalent of the existing webFrame API. More information about this new API can be found here, and in our documentation.
• app API changes:
  • Added non-localized serviceName to 'child-process-gone' / app.getAppMetrics(). #25975
  • Added new app.runningUnderRosettaTranslation property to detect when running under rosetta on Apple silicon. #26444
  • Added exitCode to render-process-gone details (app & webContents). #27677
• BrowserWindow API changes:
  • Ajout de l'API BrowserWindow.isTabletMode(). #25209
  • Added resized (Windows/macOS) and moved (Windows) events to BrowserWindow. #26216
  • Added new system-context-menu event to allow preventing and overriding the system context menu. #25795
  • Added win.setTopBrowserView() so that BrowserViews can be raised. #27713
  • Added webPreferences.preferredSizeMode to allow sizing views according to their document's minimum size. #25874
• contextBridge API changes:
  • Allowed ContextBridge exposeInMainWorld method to expose non-object APIs. #26834
• display API changes:
  • Added displayFrequency property to the Display object to allow getting information about the refresh rate on Windows. #26472
• extensions API changes:
  • Added support for some chrome.management APIs. #25098
• MenuItem API changes:
  • Ajout de la prise en charge de l'affichage du menu de partage macOS. #25629
• net API changes:
  • Ajout d'une nouvelle option credentials pour net.request(). #25284
  • Ajout de net.online pour détecter s'il existe actuellement une connexion Internet. #21004
• powerMonitor API changes:
  • Ajout de powerMonitor.onBatteryPower. #26494
  • Added fast user switching event to powerMonitor on macOS. #25321
• session API changes:
  • Ajout de l'option allowFileAccess à l'API ses.loadExtension(). #27702
  • Added display-capture API for session.setPermissionRequestHandler. #27696
  • Ajout d'une option disabledCipherSuites à session.setSSLConfig. #25818
  • Added extension-loaded, extension-unloaded, and extension-ready events to session. #25385
  • Added session.setSSLConfig() to allow configuring SSL. #25461
  • Added support for explicitly specifying direct, auto_detect or system modes in session.setProxy(). #24937
  • Added Serial API support. #25237
  • Added APIs to enable/disable spell checker. #26276
• shell API changes:
  • Added a new asynchronous shell.trashItem() API, replacing the synchronous shell.moveItemToTrash(). #25114
• webContents API changes:
  • Added a small console hint to console to help debug renderer crashes. #25317
  • Added frame and webContents properties to the details object in webRequest handlers. #27334
  • Added webContents.forcefullyCrashRenderer() to forcefully terminate a renderer process to assist with recovering a hung renderer. #25580
  • Added setWindowOpenHandler API for renderer-created child windows, and deprecate new-window event. #24517
• webFrame API changes:
  • Added spellcheck API to renderer. #25060

Modifications: éléments supprimés et dépréciés​

Les API suivantes ont été supprimées ou sont désormais dépréciées :

• Déprécié le module remote. It is replaced by @electron/remote. #25293
• Suppression des API crashReporter dépréciées. #26709
• Suppression des liens vers le site Web Electron du menu "Aide" par défaut dans les applications packagées. #25831

Fin du support pour 9.x.y​

Electron 9.x.y a atteint sa limite pour le support conformément à la politique d'assistance du projetpolitique d'assistance. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8. Bien que nous veillions à ne pas faire de promesses à propos des dates de publication, notre plan est la sortie de nouvelles versions majeures d'Electron avec de nouvelles versions de ces composants environ un trimestre. Le planning escompté de la version 13.0.0 planning défini les dates clés du cycle de vie de développement d'Electron 13.0. Aussi, regardez notre document de versioning pour plus d'informations sur le versioning dans Electron.

Pour des informations sur les changements de rupture prévus dans les versions à venir d'Electron, regardez notre documentation sur les changements de rupture planifiés.

Electron 11.0.0 est disponible ! Cette version inclue les mises à jour vers Chromium 87, V8 8.7, et Node.js 12.18.3. Nous avons ajouté la prise en charge d'Apple Silicon en plus d'autres améliorations générales. Lisez la suite ci-dessous pour plus de détails !

---

La team Electron est excitée d'annoncer la sortie de Electron 11.0.0 ! Vous pouvez l'installer via npm install electron@latest ou le télécharger depuis notre site officiel. La version est livrée avec des mises à jours, des correctifs et une nouvelle prise en charge du matériel M1 d'Apple.

On a hâte de voir vos prochaines créations avec cette version ! Continuez de lire pour plus de détails sur cette version, et s'il vous plaît, partagez vos commentaires et remarques !

Changements notables​

Changements de la Stack​

• Chromium 87.0.4280.47
  • Nouveau avec Chrome 86
  • Nouveau avec Chrome 87
• Node.js 12.18.3
  • Article de blog sur Node 12.18.3
  • Article de blog sur Node 12.7.0
• V8 8.7
  • Article de blog sur V8 8.6
  • Article de blog sur V8 8.7

Nouveautés de cette version​

• Prise en charge d'Apple M1 : le 10 novembre, Apple a annoncé leur nouvelles puces M1, qui seront incluses dans leurs prochains matériels. À partir d'Electron 11, Electron livrera des versions séparées d'Electron pour les Mac Intel (x64) et pour le prochain matériel M1 d'Apple (arm64). Vous pouvez en savoir plus sur comment faire fonctionner votre application Electron sur le matériel M1 d'Apple ici. #24545
• Ajout d’un message de plantage V8 et d’informations de localisation aux paramètres de crashReport. #24771
• Improved the performance of sending wide objects over the context bridge. #24671

Voir les notes de version 11.0.0 pour une liste complète des nouvelles fonctionnalités et des modifications.

Changements majeurs avec rupture de compatibilité​

• Removed experimental APIs: BrowserView.{fromId, fromWebContents, getAllViews} and the id property of BrowserView. #23578

Vous trouverez plus d’informations sur ces changements et les changements futurs sur la pagechangements de rupture prévus.

Changements d'API​

• Added app.getApplicationInfoForProtocol() API that returns detailed information about the app that handles a certain protocol. #24112
• Added app.createThumbnailFromPath() API that returns a preview image of a file given its file path and a maximum thumbnail size. #24802
• Added webContents.forcefullyCrashRenderer() to forcefully terminate a renderer process to assist with recovering a hung renderer. #25756

Fin du support pour 8.x.y​

Electron 8.x.y a atteint sa limite pour le support conformément à la politique d'assistance du projetpolitique d'assistance. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately quarterly. Le planning escompté de la version 12.0.0 planning défini les dates clés du cycle de vie de développement d'Electron 12.0. Aussi, regardez notre document de versioning pour plus d'informations sur le versioning dans Electron.

Pour des informations sur les changements de rupture prévus dans les versions à venir d'Electron, regardez notre documentation sur les changements de rupture planifiés.

Continued Work for Deprecation of remote Module​

We started work to remove the remote module in Electron 9. We plan to remove the remote module itself in Electron 14.

Read and follow this issue for full plans and details for deprecation.

Étape finale pour exiger que les Modules Natifs de Node soient Context Aware ou N-API (dans Electron 12)​

À partir d'Electron 6, nous avons préparé le terrain pour que les modules Node natifs chargés dans le processus de rendu, soient soit N-API ou Context Aware. L'imposition de ce changement apporte une sécurité accrue, des performances plus rapides et une charge de travail de maintenance réduite. La dernière étape de ce plan est de supprimer la possibilité de désactiver la réutilisation du processus de rendu dans Electron 12.

Read and follow this issue for full details, including the proposed timeline.

Avec la sortie de matériel Apple Silicon plus tard dans l'année, à quoi ressemble le chemin d'accès pour que votre application Electron fonctionne sur le nouveau matériel ?

---

Avec la sortie d'Electron 11.0.0-beta.1, l'équipe d'Electron est maintenant en train de livrer des versions d'Electron qui fonctionnent sur le nouveau matériel Apple Silicon qu'Apple prévoit d'expédier plus tard cette année. Vous pouvez récupérer la dernière version bêta avec npm install electron@beta ou la télécharger directement à partir de notre site des versions.

Comment ça marche ?​

À partir d'Electron 11, nous expédierons des versions séparées d'Electron pour les Mac Intel et Apple Silicon Macs. Prior to this change, we were already shipping two artifacts, darwin-x64 and mas-x64, with the latter being for Mac App Store compatibility usage. We are now shipping another two artifacts, darwin-arm64 and mas-arm64, which are the Apple Silicon equivalents of the aforementioned artifacts.

Que devez-vous faire ?​

You will need to ship two versions of your app: one for x64 (Intel Mac) and one for arm64 (Apple Silicon). The good news is that electron-packager, electron-rebuild and electron-forge already support targeting the arm64 architecture. As long as you're running the latest versions of those packages, your app should work flawlessly once you update the target architecture to arm64.

In the future, we will release a package that allows you to "merge" your arm64 and x64 apps into a single universal binary, but it's worth noting that this binary would be huge and probably isn't ideal for shipping to users.

Update: This package is now available at @electron/universal. You can use it to merge two packaged x64 and arm64 apps into a single binary.

Problèmes potentiels​

Modules natifs​

Comme vous visez une nouvelle architecture, vous devrez mettre à jour plusieurs dépendances qui peuvent causer des problèmes de construction. La version minimale de certaines dépendances est incluse ci-dessous pour votre référence.

Dependency	Version Requirement
Xcode	>=12.2.0
node-gyp	>=7.1.0
electron-rebuild	>=1.12.0
electron-packager	>=15.1.0

As a result of these dependency version requirements, you may have to fix/update certain native modules. One thing of note is that the Xcode upgrade will introduce a new version of the macOS SDK, which may cause build failures for your native modules.

Comment puis-je le tester ?​

Currently, Apple Silicon applications only run on Apple Silicon hardware, which isn't commercially available at the time of writing this blog post. If you have a Developer Transition Kit, you can test your application on that. Otherwise, you'll have to wait for the release of production Apple Silicon hardware to test if your application works.

Qu’en est-il de Rosetta 2 ?​

Rosetta 2 is Apple's latest iteration of their Rosetta technology, which allows you to run x64 Intel applications on their new arm64 Apple Silicon hardware. Although we believe that x64 Electron apps will run under Rosetta 2, there are some important things to note (and reasons why you should ship a native arm64 binary).

• Your app's performance will be significantly degraded. Electron / V8 uses JIT compilation for JavaScript, and due to how Rosetta works, you will effectively be running JIT twice (once in V8 and once in Rosetta).
• You lose the benefit of new technology in Apple Silicon, such as the increased memory page size.
• Avons-nous mentionné que la performance sera significativement dégradée?

Join us for community bonding and a month-long celebration of open-source.

---

Electron Community Discord Launch

Electron’s Outreach Working Group is excited to announce the launch of our official community Discord server!

Pourquoi un nouveau serveur Discord ?​

In its early days as the backbone of the Atom text editor, community discussion on the Electron framework occurred in a single channel in Atom’s Slack workspace. As time passed and the two projects were increasingly decoupled, the relevance of the Atom workspace to the Electron project decreased, and maintainer participation in the Slack channel declined in the same manner.

Up until now, we had still been redirecting our broader community to the Atom Slack workspace, even though we’ve had many reports from folks who have had trouble receiving invitations, and few of our core maintainers were frequenting the channel.

We’re setting up this shiny new server to be a central discussion hub for the community where you can get the latest news on all things Electron.

Get in here!​

So far, the server’s membership consists of a few maintainers who have been working together to set it up, but we’re so excited to chat with you all! Come ask for help, keep up to date with Electron releases, or just hang out with other developers. We’ve got a handy invite for you that’ll give you access to the server!

Hacktoberfest 2020

As a large and long-running open-source project, Electron wouldn’t have been nearly as successful without all the contributions from its community, from code submissions to bug reports to documentation changes, and much more. That’s why we believe in the importance of participating in Hacktoberfest to usher in a wider community of developers of all skill levels into the project.

Odds and ends​

This year, we don’t have a wider project to give you all to work on, but we’d like to focus on opportunities to contribute across the Electron JavaScript ecosystem.

Faites Attention aux problèmes marqués hacktoberfest sur nos différents référentiels, y compris le principal electron/electron, le site electron/electronjs.org , electron/fiddle, et electron-userland/electron-forge !

P.S. Si vous vous sentez particulièrement aventureux et à la recherche de défis., nous avons également un arriéré de problèmes marqués par les tags help wanted.

Bloqué ? Come chat with us!​

Moreover, it’s also no coincidence that the grand opening of our Discord server coincides with the largest celebration of open-source software of the year. Check out the #hacktoberfest channel to ask for help on your Hacktoberfest PR. Au cas où vous l’auriez manqué, voici le lien d’invitation à nouveau!

Electron 10.0.0 est disponible ! Cette version inclue les mises à jour vers Chromium 85, V8 8.5, et Node.js 12.16. Nous avons ajouté plusieurs nouvelles intégrations et améliorations de l'API. Lisez la suite ci-dessous pour plus de détails !

---

La team Electron est excitée d'annoncer la sortie de Electron 10.0.0 ! Vous pouvez l'installer via npm install electron@latest ou le télécharger depuis notre site officiel. Cette version inclue des mises à jour, des correctifs et de nouvelles fonctionnalités.

Dans cette version 10 de Electron, nous avons également modifié notre note de sorte. Pour qu'il soit plus facile de distiniguer ce qui est nouveau dans Electron 10 et ce qui peut avoir changé entre Electron 10 et les versions précédentes, nous incluons maintenant également des changements qui ont été introduits dans Electron 10, mais qui ont été rétroportés aux versions précédentes. Nous espérons que cela rendra l'intégration de nouvelles fonctionnalités et corrections plus facile pour les applications lors des mises à niveau d'Electron.

On a hâte de voir vos prochaines créations avec cette version ! Continuez de lire pour plus de détails sur cette version, et s'il vous plaît, partagez vos commentaires et remarques !

Changements notables​

Changements de la Stack​

• Chromium 85.0.4183.84
  • Nouveau avec Chrome 84
  • Nouveau avec Chrome 85
• Node.js 12.16.3
  • Article de blog sur Node 12.16.3
• V8 8.5
  • Article de blog sur V8 8.4
  • Article de blog sur V8 8.5

Nouveautés de cette version​

• Added contents.getBackgroundThrottling() method and contents.backgroundThrottling property. [#21036]
• Exposed the desktopCapturer module in the main process. #23548
• Can now check if a given session is persistent by calling the ses.isPersistent() API. #22622
• Resolve network issues that prevented RTC calls from being connected due to network IP address changes and ICE. (Chromium issue 1113227). #24998

Voir les notes de version 10.0.0 pour une liste complète des nouvelles fonctionnalités et des modifications.

Changements majeurs avec rupture de compatibilité​

• Changed the default value of enableRemoteModule to false. #22091
  • This is part of our plans for deprecating the remote module and moving it to userland. You can read and follow this issue that details our reasons for this and includes a proposed timeline for deprecation.
• Changed the default value of app.allowRendererProcessReuse to true. #22336 (Also in Electron 9)
  • This will prevent loading of non-context-aware native modules in renderer processes.
  • You can read and follow this issue that details our reasons for this and includes a proposed timeline for deprecation.
• Fixed the positioning of window buttons on macOS when the OS locale is set to an RTL language (like Arabic or Hebrew). Frameless window apps may have to account for this change while styling their windows. #22016

Vous trouverez plus d’informations sur ces changements et les changements futurs sur la pagechangements de rupture prévus.

Changements d'API​

• Session: Can now check if a given session is persistent by calling the ses.isPersistent() API. #22622
• Contents: Added contents.getBackgroundThrottling() method and contents.backgroundThrottling property. #21036

Deprecated APIs​

The following APIs are now deprecated or removed:

• Removed the deprecated currentlyLoggingPath property of netLog. Additionally, netLog.stopLogging no longer returns the path to the recorded log. #22732
• Deprecated uncompressed crash uploads in crashReporter. #23598

Fin du support pour 7.x.y​

Electron 7.x.y a atteint sa limite pour le support conformément à la politique d'assistance du projetpolitique d'assistance. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8. Bien que nous veillions à ne pas faire de promesses à propos des dates de publication, notre plan est la sortie de nouvelles versions majeures d'Electron avec de nouvelles versions de ces composants environ un trimestre. Le planning escompté de la version 11.0.0 planning défini les dates clés du cycle de vie de développement d'Electron 11.0. Aussi, regardez notre document de versioning pour plus d'informations sur le versioning dans Electron.

Pour des informations sur les changements de rupture prévus dans les versions à venir d'Electron, regardez notre documentation sur les changements de rupture planifiés.

Poursuite du travail pour la dépréciation du module remote (dans Electron 11)​

Nous avons commencé à travailler pour supprimer le module remote dans Electron 9 et nous continuons à envisager de supprimer le module remote. Dans Electron 11, nous prévoyons de poursuivre le travail de refactorisation pour l'implémentation de WeakRef comme nous l'avons fait avec Electron 10. Veuillez lire et suivre ce problème pour tous les plans et détails de la dépréciation.

Étape finale pour exiger que les Modules Natifs de Node soient Context Aware ou N-API (dans Electron 12)​

Edit : À l'origine, ce billet de blog indiquait que nous désactiverions la réutilisation du processus de rendu dans Electron 11. La désactivation de la réutilisation du processus de rendu a maintenant été poussée vers Electron 12.

À partir d'Electron 6, nous avons préparé le terrain pour que les modules Node natifs chargés dans le processus de rendu, soient soit N-API ou Context Aware. L'imposition de ce changement apporte une sécurité accrue, des performances plus rapides et une charge de travail de maintenance réduite. La dernière étape de ce plan est de supprimer la possibilité de désactiver la réutilisation du processus de rendu dans Electron 12. Lisez à propos ce problème pour tous les détails, y compris le calendrier proposé.

At OpenJS World this morning, we announced that Electron has officially graduated from the OpenJS Foundation's incubation program, and is now an OpenJS Foundation Impact Project.

Electron entered incubation in December of 2019, at the last OpenJS Foundation global conference in Montreal. We're excited to take a larger role in the JavaScript community as an Impact Project, and continue our partnership with the OpenJS Foundation.

---

Learning more​

You can read up on the foundation, its mission, and its members on the OpenJSF website. The OpenJS Foundation is host to a number of open source JavaScript projects including jQuery, Node.js, and webpack. It's supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft.

Electron is an open–source framework for building cross-platform desktop applications with web technologies. To learn more about the humans behind Electron and how they work together, take a look at our Governance page.

To get started with Electron itself, take a peek at our documentation.

Electron est fier de participer à la deuxième édition de l'initiative de Google Season of Docs, qui associe des mentors d'organisations open source avec des rédacteurs techniques pour améliorer la documentation du projet.

---

Qu'est-ce que Season of Docs ?

Season of Docs est un programme qui favorise la collaboration entre les rédacteurs techniques et les communautés open source au profit des deux parties. Les responsables de l’open source utilisent l’expertise technique de rédaction de l’auteur pour améliorer la structure et le contenu de leur documentation, tandis que le rédacteur technique est présenté à une communauté open source sous la direction de ses mentors. En savoir plus à ce sujet sur le site Web de google Season of Docs.

Pour la première fois que nous participerons au programme, nous encadrerons un seul rédacteur technique qui travaillera aux côtés du groupe de travail sur l’écosystème d’Electron pour remodeler de grandes parties de notre documentation. Vous pouvez en savoir plus sur la chronologie de l’ensemble du projet ici.

Comment s'inscrire ?

Êtes-vous intéressé à collaborer avec nous en tant que rédacteur technique ? Tout d’abord, familiarisez-vous avec le guide du rédacteur technique de Google pour le programme de cette année et consultez les deux ébauches d’idées de projet que nous avons préparées.

Afin d’être sélectionnés en tant que rédacteur technique d’Electron pour Season of Docs, les candidats devront postuler sur le site Web google Season of Docs pendant la phase de candidature rédatcteur technique qui se déroule du 8 juin au 9 juillet..

Your application should include a proposal, which is a written document that describes in detail what you plan to achieve on the Electron docs over the course of 3 months. This proposal can either develop on one of the starting points mentioned in our Project Idea doc, or can be something entirely new. Don't know where to start? You can check out last year's list of accepted proposals for inspiration.

Aside from the proposal, we'll also be looking at your background as a technical writer. Please include a copy of your resume with an emphasis on relevant writing experience, as well as technical writing samples (these samples could be existing documentation, tutorial, blog posts, etc.)

If you want to discuss project proposals, shoot us an email at season-of-docs@electronjs.org and we can chat from there!

Références

• Documentation d'Electron
• Document d’idées de projet
• Guide du rédacteur technique de Season of Docs