Version importante pour le framework, qui permet pour rappel de faire fonctionner des applications sur plusieurs plateformes en faisant appel à HTML, aux CSS et à JavaScript. Le cadriciel se sert de Chrome pour le rendu et de Node.js et V8 pour le traitement en arrière-plan.
Les applications Electron subissaient jusqu'ici une importante dégradation de leurs performances sur les Mac M1. Et pour cause : compilées pour des environnements x86, elles étaient récupérées par Rosetta 2 dans Big Sur, exécutant alors deux fois la compilation JIT.
La solution est donc Electron 11.0, qui bénéficie désormais d’un support complet avec les puces M1. Les développeurs sont invités à recompiler leurs applications pour profiter de l’apport significatif en performances ainsi que certains bonus spécifiques à M1, comme la taille plus importante de la page mémoire.
Pour s’assurer qu’il n’y aura pas de confusion, l’équipe fournit deux versions séparées d’Electron : une pour plateformes x64, l’autre pour les Mac M1 (ARM64). Elle a réfléchi à la possibilité d’une compilation qui fournirait les deux codes en un seul binaire, mais le jeu n’en vaudrait pas la chandelle, le poids de l’application grimpant en flèche.
Cette compatibilité est le plus gros apport d’Electron 11.0, mais quelques autres améliorations sont présentes, comme l’ajout d’un message de plantage pour V8 et d’informations de localisation pour les paramètres de crashReport, ou encore l’arrivée de webContents.forcefullyCrashRenderer() pour tuer un processus de rendu.
À noter que depuis la publication de la version 11.0, deux moutures 11.0.1 et 11.0.2 ont été fournies pour régler quelques bugs de jeunesse.
Commentaires (8)
#1
Du coup Electron ne fait pas d’application universelle et nécessite une compilation spécifique par processeur?
Une autre bonne raison de préférer une vraie app a ça…
#1.1
Heu… comment dire que bon, que pour faire une application, il faut à un moment donner fournir un binaire qui soit interprétable par la machine. Donc oui, il y a toujours un truc qui sera spécifique à un environnement (OS+processeur).
#1.2
Ça dépend, on pourrait imaginer “pas de binaire”, c’est le cas dans pas mal de langages interprétés. Si l’interpréteur est intégré à l’OS (macOS intègre Python, et a longtemps intégré Java par exemple) pas besoin de binaire par app.
D’ailleurs, pour moi, on peut tout à fait faire une application .app macOS qui n’intègre pas de binaire, avec par exemple un fichier .sh ou .py comme principal fichier exécutable.
#1.3
Oui, mais comme tu le dis, ça ne fonctionne que si le langage est interprété et que l’interpréteur est intégré à l’OS (a ceci, il faut rajouter que les interpréteurs garantissent tous le même comportement). Dans le cadre d’une application simple à installer et universelle, ce n’est pas gagné.
Tu n’a pas beaucoup d’interpréteur intégré commun à tous les OS, le seul que je vois, c’est HTML/CSS+JS car on va très certainement trouvé un navigateur Web dans un OS. Cependant, tu ne peux pas garantir que ce navigateur soit à la bonne version et intègre toutes les fonctionnalité que tu as besoin (fonction absente car trop récente ou au contraire dépréciée et retirée).
Il est donc assez logique que pour maîtriser ton environnement, il faut rajouter l’interpréteur dans ton “package”. C’est ce que fait Electron en intégrant blink et NodeJS. Il assure au passage que ça sera des versions précises, les extension NodeJS soit celles que tu as choisies…
PC : pour faire beaucoup de python, du pure python, c’est un langage très inefficacequi est très lent (sans compter le problème de GIL et du multithread de CPython) et pratiquement impossible d’utiliser efficacement un compilateur JIT (le byte code cpy nécessite encore beaucoup de travail lors de l’execution). Ce n’est donc pas rare que les bibliothèque python sont en faite en C/C++ et que le package contiennent directement le code compiler (numpy par exemple).
#1.4
D’ou les App Universelles autrefois PowerPC/Intel et maintenant ARM/Intel. Un package, deux binaires partageant toutes les ressources communes.
#1.5
C’est justement discuté dans l’article pour le cas d’électron :
#2
Une application universelle est une app compilée pour chaque processeur par un compilateur (plus ou moins spécifique), puis les deux binaires sont fournis ensemble.
C’est plus pratique pour l’utilisateur (un seul lien de téléchargement, que ce sot mac intel ou mac arm) mais c’est pas si dramatique donc si Electron fournit deux binaires, un intel, un arm.
Cela dit, on voit que le but de Electron, c’est d’en faire le moins possible pour fournir un logiciel, c’est profondément une solution “bas de gamme”.
#3
“le poids de l’application grimpant en flèche.” déjà que Electron pèse un âne mort