Développement : Electron est-il le nouveau Flash ?
Vous ne connaissez peut-être pas le nom d’Electron, mais vous l’utilisez sans doute sans le savoir. De nombreuses apps pour ordinateurs utilisent cette technologie, que ce soit sur macOS, sur Windows ou sur Linux. Et pour cause, ce framework est conçu pour développer des applications multiplateformes en utilisant des technologies du web.
Sous le capot, Electron est constitué d’un serveur en JavaScript (node.js) et il exploite Chromium, le moteur d’affichage open-source de Google, pour son interface. Les apps Electron ont l’apparence d’interfaces natives, mais elles sont en fait codées en HTML, CSS et JavaScript. Tout ce bagage technologique ressemblera peut-être à du chinois si vous n’êtes pas développeur, mais il est essentiel pour comprendre le problème.
En optant pour des technologies du web plutôt que pour les outils natifs spécifiques à chaque plateforme, Electron simplifie le travail des développeurs. Et de fait, le framework créé à l’origine par GitHub est désormais très largement exploité : la messagerie instantanée Slack, les éditeurs de code Atom et Visual Studio Code, les apps des blogs WordPress et Ghost, l’éditeur Markdown Caret, le gestionnaire de notes Simplenote ou encore le client mail Nylas sont quelques exemples parmi tant d’autres.
La contrepartie de cette simplicité, c’est que les performances ne sont pas aussi bonnes qu’avec un développement natif. C’est toujours le cas avec les technologies multiplateformes, mais Electron est particulièrement mal placé en la matière. Il repose sur le navigateur de Google qui n’est pas connu pour sa légèreté et il est très facile de développer des apps sans les optimiser et en faire des gouffres à mémoire vive.
À l’arrivée, une app très utilisée comme Slack reçoit régulièrement des critiques de la part d’utilisateurs surpris qu’une messagerie nécessite autant de ressources. C’est elle qui a suscité l’analogie entre Electron et Flash chez un développeur, alors que l’app à l’arrière-plan monopolisait toutes les ressources de son Mac. Il a collaboré sur le noyau de Chrome et il sait ainsi que c’est un immense projet qui contient autant de lignes de code que le noyau de Linux et qui gère des cas de figure complètement inutiles pour Electron.
Est-ce que l’équipe de Slack a pris soin de modifier Chromium pour l’adapter à ses besoins ? Probablement pas, ce qui explique son poids (163 Mo sur macOS pour la dernière version) et son aptitude à consommer beaucoup trop de RAM. On évoque cette app, mais c’est la même chose pour tous ceux qui exploitent Electron. L’éditeur de code Atom développé par GitHub pour qui Electron a été mis en place dépasse les 270 Mo sur le SSD, pour prendre un autre exemple.
Au-delà de l’utilisation des ressources, ces apps peuvent être très difficiles à optimiser. Microsoft utilise Electron pour Visual Studio Code et l’éditeur a fait face à un bug assez hallucinant. Sur macOS uniquement, le curseur clignotant de cet éditeur de code consomme à lui seul environ 13 % de CPU. Ce curseur est affiché et masqué en CSS et un bug de Chromium utilise trop le processeur sur le système d’Apple. L’entreprise a fini par trouver une solution qui devrait être disponible prochainement dans la version finale, mais cet exemple illustre bien la difficulté apportée par Electron.
Même GitHub, créateur d’Electron, a du mal à optimiser ses apps et notamment pour accélérer les temps de lancement. Une prochaine version d’Atom, son éditeur de code, se lancera 50 % plus rapidement que la précédente. C’est très bien, mais cela prouve qu’il reste encore beaucoup de place pour optimiser et aussi que ce n’est pas simple, puisqu’il y a beaucoup de facteurs et d’acteurs à prendre en compte.
Ces applications Electron sont aussi parfois plus limitées que les équivalents natifs. Pour rester sur l’exemple d’Atom, le logiciel n’était pas capable d’ouvrir des fichiers de plus de 2 Mo pendant très longtemps. On peut maintenant le faire, mais un message d’alerte indique que les performances ne seront pas bonnes. Et il ne faut pas compter sur certaines fonctions importantes, comme la coloration syntaxique. En comparaison, un logiciel concurrent natif comme TextMate est peut-être un petit peu plus lent, mais il garde toutes ses fonctions.
Electron est une belle idée et le framework a permis effectivement à de nombreuses apps pour ordinateurs d’exister sur toutes les plateformes. La souplesse offerte par les technologies du web est indéniable aussi et ces apps sont plus faciles à développer au premier abord. Mais il y a des contreparties à prendre en compte face aux avantages et la multiplication des projets Electron n’est pas forcément une bonne nouvelle.
Ne terminons pas sur une note négative. Comme tout projet logiciel, Electron est appelé à évoluer et ses concepteurs peuvent se concentrer sur l’optimisation des performances. Par ailleurs, il devrait aussi profiter des optimisations menées depuis plusieurs années par Google sur Chrome.
Un logiciel auteur … Arg ?
OCaml !
Ce n'est pas demain qu'on se passera des technos natives, donc ?
Oui et non. Oui, pour tout ce qui est bas niveau. Non, pour le reste et sans attendre. Electron est particulièrement lourd, une machine virtuelle Java ou Python l'est beaucoup moins.
Électron est la suite logique de l'évolution informatique : dès qu'on a plus de puissance à disposition, on abandonne l'optimisation pour d'autres critères (multiplateforme, plus rapide à développer, plus de développeurs qui connaissent le langage X, technologie plus "hot").
Je trouve ça dommage, notamment parce que certains avantages passent par la fenêtre (l'autonomie qu'on pourrait tirer ? de logiciels plus optimisés, ne plus entendre les ventilateurs de l'ordi pour un rien)
Il ne faut tout rejeter pour autant et coder en assembleur parce que l'abstraction c'est le mal, mais il y a un juste milieu quand même.
C'est pour ça que je trouve le compromis de Swift très intéressant avec une abstraction assez élevée, mais qui est payée au moment de la compilation et non de l'exécution.
(On peut voir Le parallèle avec les applications iOS qui font toutes 150Mo pour encapsuler des vues web, tout simplement parce que "on a la place" ?)
Je suis d'accord avec toi pour penser qu'il y a un juste milieu, entre le misérable Electron et l'innaccessible assembleur.
Continuons à développer en Obj-C pour iOs ou en Java pour Android (ou en Swift si ça vous chante et si vous aimez les compilations 60 fois moins rapides)
Et laissons ces fâcheux outils multi-plateforme aux amateurs de miroirs et d'alouettes.
Par contre, là où je ne te suis pas c'est sur ta dernière phrase : quand ça m'est arrivé d'ajouter une UIWebView à une app vierge (ou à une de mes apps), ça ne rajoutait que quelques lignes de code.
Où diable va tu chercher que ça ferait 150 Mo d'encapsuler des vues web ?
Ça peut éventuellement être vrai si lesdites vues sont très lourdes, mais ça ne vient pas de l'encapsulation elle même ou du langage, à mon avis.
@pecos
Si tu le fais avec Ionic ou Sencha ExtJS Mobile (qui utilise Cordova), tu obtiens vite une application assez lourde. Avec Appcelerator Titanium, tu produit des apps assez lourdes aussi (Ça utilise JavaScriptCore, le moteur JavaScript de Safari qui communique avec leur SDK "natif").
La seul technologie web pour le multiplateforme mobile/desktop qui me semble tenir assez bien ses promesses, c'est React Native.
OK, j'avais pas compris : vu le message précédent je croyais qu'il s'agissait d'apps natives avec des UIwebviews utilisées par "convenance". Ça m'est arrivé au début, et j'ai vite arrêté... ;-)
Je comprends maintenant qu'avec ces frameworks, non seulement ça n'est pas rapide, mais en plus ça produit des apps inutilement lourdes !
C'est pas la joie...
@pecos
Justement. Encapsuler une vue web devrait être très léger, d'autant plus en utilisant le WebKit intégré à iOS. Je me plains juste de certaines applications qui m'ont l'air d'être qu'une vue web tellement elles semblent "non natives" et de leur poids.
Mais ça doit être la faute des SDK "à la Electron" (mais sur iOS bien sûr) qui utilisent du JavaScript où je ne sais quoi pour faire une app pataude et en plus lourde.
Ca ressemble aux applications HTA exécutées par un Internet Explorer OPEN BAR mshta.exe. Ca a donné le fameux virus ILOVEYOU
@frankm :
Aucun rapport !
Le virus "I love you" était écrit en VB script, langage proche de Visual Basic destiné à faire concurrence à JavaScript mais supporté au départ uniquement par IE. Le problème est survenu quand MS à décidé de permettre l'exécution de fichiers .vbs directement par simple double clic dessus sans demande de confirmation. Ça plus le fait que par défaut Windows (macOS aussi désormais ) n'affiche pas les extensions des fichiers à été fatal.
Le fichier étant nommé iloveyou.txt.vbs, quand les gens ont reçu un mail avec la chose en PJ, ils n'ont vu que iloveyou.txt et ont cru qu'il ne s'agissait que de texte ! Donc double clic et patatra !
@ marc_os : « Ça plus le fait que par défaut Windows (macOS aussi désormais ) n'affiche pas les extensions des fichiers »
Non, Mac OS n’est pas réglé par défaut pour masquer les extensions des noms de fichier.
En fait, il n’existe même pas de possibilité de faire ça dans Mac OS (il n’existe que l’option inverse : forcer l’affichage de l’extension pour tous les fichiers en ignorant le choix fait individuellement pour chaque fichier).
D’autre part, il est impossible dans Mac OS de masquer l’extension d’un fichier dont le nom se termine par deux extensions connues — un fichier « iloveyou.txt.app » ne pourrait pas être affiché simplement comme « iloveyou.txt ».
J'ai deja utilisé cordova(ex phonegap) pour des app multiplateforme et le résultat est sans appel: les promesses sont pas tenues et le "code once run everywhere" est tres loins d'être vrai, j'ai du developper des plugins natifs pour ios (et autre devs pour android et blackberry) et les perf était .. ridiculement basse.
Alors jamais j'utiliserais une technologie comme celle la jamais !
Et pourquoi Adobe ne met tout simplement pas à jour flash avec une version faire pour les outils numériques actuels ?
D'après ce que j'ai compris on remplacera flash par électron ?
Non, un dév a fait une analogie entre Flash et Electron.
Oubliant qu'Adobe n'a jamais vraiment migré sous Flash pour en faire un truc sexy (héritage du rachat de Macromedia...).
Je pense que l'erreur n'est pas Electron, il va évoluer, peut-être choisir un truc plus performant que Chromium, Node.js est aussi suffisamment jeune pour s'améliorer etc.
Non, l'erreur est qu'Apple / MS / Linus / Berkeley ne s'entendrons JAMAIS sur un framework natif commun.
Une fois que l'on a assimilé ça, alors Electron à toute sa place sur des usages marginaux et des applications natives ont leur place pour des usages intensifs.
On peut montrer du doigt QT (Pas QuickTime, même si QuickTime fait partie de la liste...), Flash, Electron, java (côté desktop hein) etc.
Mais montrons aussi du doigt Apple / MS / etc pour leurs incapacités à lâcher du mou sur l'enfermement du développement logiciel à leur plateforme...
Les 2 vérités sont au même niveau...
@ Un Type Vrai : « On peut montrer du doigt QT (Pas QuickTime, même si QuickTime fait partie de la liste...), Flash, Electron, java (côté desktop hein) etc.
Mais montrons aussi du doigt Apple / MS / etc pour leurs incapacités à lâcher du mou sur l'enfermement du développement logiciel à leur plateforme...
Les 2 vérités sont au même niveau... »
Pas vraiment au même niveau, non.
Ce que tu appelles « l’enfermement du développement logiciel à leur plateforme », ça s’appelle développer un système d’exploitation.
Avoir ce « framework natif commun » dont tu parles, ça reviendrait peu ou prou à n’avoir plus qu’un seul OS, car contrairement à ce dont est convaincu Linus Torvalds ce n’est pas son noyau qui définit ce qu’est un OS, mais les fonctions qu’il propose aux utilisateurs (via son interface utilisateur) et aux développeurs d’applications (via l’API d’accès à son framework de développement). Ces deux derniers éléments étant très fortement liés, avoir tous les OS reposant sur le même framework les conduirait à avoir aussi à peu près la même interface utilisateur (à quelques questions décoratives près), pour proposer un accès aux mêmes fonctionnalités (forcément, puisqu’elles sont liées au framework). Donc, en gros, il n’y aurait plus qu’un seul OS.
Certains développeurs d’applications en rêvent, pas mal de gestionnaires de parc aussi.
Moi, non. Et il semble que « quelques » autres utilisateurs n’en rêvent pas non plus. ;-)
J'attendais ça...
"Ce que tu appelles « l’enfermement du développement logiciel à leur plateforme », ça s’appelle développer un système d’exploitation."
Ben non. Preuves ?
Qt fonctionne déjà sous Mac OS X / Windows / Linux
Mac OS X et iOS partagent les mêmes API sans partager les mêmes interfaces.
Cocoa peut fonctionne sur windows...
Et même l'origine de Cocoa (et Next), c'est un framework natif qui gère les interfaces différentes selon les OS (D'où Interface Builder, les controlleurs etc).
On peut avoir des API compatibles avec des implémentations et des interfaces différentes...
Il n'y a aucun effort dans ce sens, que ce soit inter OS, ou même simplement entre Gnome et KDE...
La vision actuelle est de partager à la marge (OpenGL,OpenAL, API d'impression, ...)
Mais on pourrait imaginer plus de collaboration.
Là ou je suis d'accord, c'est que ce n'est pas dans l'intérêt d'Apple, de Microsoft et de Google...
Mais c'est largement possible techniquement (et utopiste dans la vraie vie).
Mon point : Si des "monstres" comme Qt, Flash, Electron arrivent, c'est parce que ce n'est pas des monstres. Juste un besoin non adressé à la bonne personne...
POSIX !
Ha pardon ça a 40 ans. Parait qu'on a évolué en mieux depuis, qu'on est une meilleure humanité, tout ça, Mars, etc.
Fut un temps, j'ai fantasmé sur openstep, et aussi Corba, oui madame.
@oomu
S'il y a bien une chose qui ne m'a jamais fait phantasmer, c'est bien CORBA. Ah ça non.
@ oomu : « Fut un temps, j'ai fantasmé sur openstep, et aussi Corba, oui madame. »
Chacun ses perversions… :-)
Vu que l'heure est à la nostalgie, on sait bien que l'avenir du fantasme "write-once, deploy everywhere" c'est la Yellow Box :-))
@ Un Type Vrai : « J'attendais ça... »
Preuve que tu en étais conscient — sans doute parce que tu sais que c’est vrai. ;-)
« Ben non. Preuves ? »
Je n’en attendais pas particulièrement. Ça tombe bien, car tu n’en as pas apporté. :-D
« Qt fonctionne déjà sous Mac OS X / Windows / Linux »
Sauf que Qt n’a pas grand chose à voir avec ce que tu proposais.
« Mac OS X et iOS partagent les mêmes API sans partager les mêmes interfaces. »
Ils ne partagent pas toutes les mêmes API, justement en raison de leurs différences.
« Et même l'origine de Cocoa (et Next), c'est un framework natif qui gère les interfaces différentes selon les OS (D'où Interface Builder, les controlleurs etc). »
Non, ce n’en est pas du tout l’origine de NeXT, ni d’Interface Builder. Tu confonds avec le fait qu’il y a eu, des années plus tard, une tentative de création d’un framework multiplateformes sur cette base (framework qui ne gérait pas des interfaces vraiment différentes).
« On peut avoir des API compatibles avec des implémentations et des interfaces différentes... »
Oui, mais les interfaces pilotées via ces API seront forcément très proches (dans leur fonctionnement, qui compte bien plus que leur aspect).
Soyons clairs : tu parlais d’un « framework natif commun » pour mettre fin à un soi-disant « enfermement du développement logiciel à chaque plateforme ».
Ça signifie donc d’avoir en commun le jeu complet d’API des OS concernés, chacun ne pouvant donc plus proposer des fonctionnalités non disponibles sur les autres. Parce que sinon, on retombe dans le cas connu depuis toujours avec les frameworks multiplateformes incomplets :
• soit la majorité des développeurs d’applications n’utilisent que le jeu d’API commun — et on peut donc bien considérer qu’on n’a qu’un seul OS, disponibles en diverses versions intégrant juste quelques différences cosmétiques ;
• soit les développeurs font l’effort d’utiliser, en complément des API communes, les spécificités de telle ou telle plateforme, et on retombe dans cet « enfermement » que tu voulais éviter.
Mais cette situation, on l’a déjà depuis un moment, notamment avec Qt. Pas sûr qu’on ait besoin de perdre du temps avec un framework multiplateforme de plus, surtout si sont développement doit se faire au prix du ralentissement du développement des OS.
« La vision actuelle est de partager à la marge (OpenGL,OpenAL, API d'impression, ...)
Mais on pourrait imaginer plus de collaboration. »
On pourrait. Mais franchement, il y en a déjà pas mal, de collaboration. Ce qui compte le plus, c’est de s’assurer que l’invisible (la partie modèle des applications) soit facilement portable. Mais aller vers plus de compatibilité pour la partie interface utilisateur, c’est saboter une partie de ce qui définit ces interfaces et les distingue les unes des autres.
« Là ou je suis d'accord, c'est que ce n'est pas dans l'intérêt d'Apple, de Microsoft et de Google... »
Ce n’est pas non plus dans mon intérêt en tant qu’utilisateur de Mac.
« Mais c'est largement possible techniquement (et utopiste dans la vraie vie). »
Évidemment que c’est techniquement possible ! Ce qui ne signifie en rien que ce soit souhaitable.
« Mon point : Si des "monstres" comme Qt, Flash, Electron arrivent, c'est parce que ce n'est pas des monstres. Juste un besoin non adressé à la bonne personne... »
Ce sont des monstres qui arrivent parce que certains ont besoin de tels monstres.
Ça n’en fait pas moins des monstres.
"car contrairement à ce dont est convaincu Linus Torvalds ce n’est pas son noyau qui définit ce qu’est un OS, mais les fonctions qu’il propose aux utilisateurs (via son interface utilisateur) et aux développeurs d’applications (via l’API d’accès à son framework de développement"
Violemment NON !
@ oomu : « Violemment NON ! »
Ben pourtant si.
non. la définition de Torvald est beaucoup plus légitime.
Un noyau définit un os : son architecture, son fonctionnement interne, ses choix aux profondes conséquences, ses fonctionnalités et priorités etc.
De fait que même avec les unix de toutes sortes sous CDE, ou linux ou freebsd noyés sous les utilitaires BSD (voir gnu), on a clairement à faire à deux systèmes différents à cause de leur noyau.
Il est difficile d'imposer une définition unique d'un OS (vous en avez la preuve en ce moment même avec moi et vous ne pourrez pas me balayer d'un revers de la main, ce débat existe depuis des décennies dans une foule de forums et journaux)
un noyau vs utilitaires
api vs frameworks
ou
interface vs implémentations
etc
Mais il y a une constante: le noyau reste difficile à éliminer de ce qui définit un OS. Et ce malgré de nombreuses tentatives industrielles et académiques.
On en arrive aux os très resserrés, autour d'un noyau ou micro-noyau + quelques utilitaires très stricts pour définir un os.
xnu, linux/android et autre qnx. Tout le reste au dessus étant du décorum.
Dans un monde Apple idéal, les rédacteurs nous feraient de jolis tableaux comparatifs avec les technologies employées et une case de mesures "Energie consommée" avant même de contempler le Samsung Galaxy S8 sous toutes les coutures, ou de disserter bientôt sur le futur Samsung S9.
Ainsi par famille de logiciels, avec ce critère et d'autres, on pourrait faire des choix pragmatiques.
En effet, mais l'AppStore préfère masquer ce type de chose :)
Poids du logiciel, % de l'interface sur la surface de l'écran, compatibilité fullscreen, mémoire moyenne utilisée, ...
Y'a PLEIN de métriques que l'on peut toucher un peu vaguement du doigt qu'en ayant téléchargé, essayé etc TOUS les concurrents possibles...
Et on trouve rarement un comparatif objectif.
Si le travail d'un journaliste était de rassembler des donnés présentent sur un site, je pense qu'on pourrait facilement les remplacer par un script..
Non ce que demande ici notre ami est un vrai travail de fond, avec en effet de l'investigation, de l'achat d'outils soft ou hard et un travail d'analyse.
Bref comme il dit: dans un monde de presse Apple idéal...
Me semble que Spotify utilise aussi Electron non? Ou en tous cas Chromium
Spotify? Galaxy Client (gog.com)? utilisent Électron alors?
Ça explique pas mal de choses sur les fuites de mémoire et la lourdeur non?
J'utilise atom pour python en ce moment. J'analyse des données de fichiers textes et je crée des graphiques. Un autre éditeur serait plus rapide que Atom pour python ?
Merci pour vos conseils :)
@Shew
sublime text3
@a_y
Merci ! J'vais tester pour voir :)
@Shew
PyCharm. Très excellent.
@fte
Merci je vais essayer :)
Ce qui me fait suer c'est que cela va permettre à Google Chrome de progresser, et de tout tuer...
Il y a quand même des technos ou des logiciels multi-plates-formes qui sont assez performants (qui n'utilisent pas Java, donc...)
Je trouve que Sublime Text est un bon compromis et je l'utilise sur Windows/Linux/macOS (avec une seule licence !) Par ailleurs, avec les portages de Qt on arrive à des logiciels corrects un peu partout.
J'aime bien Atom mais il est effectivement trop lourd et c'est aussi parce que ce n'est pas qu'un éditeur. Il est très plastique et peut se transformer en IDE pour certains langages (p.ex. Julia), pas autant qu'Eclipse mais c'est un peu l'idée.
C'est peut-être maladroit de comparer Electron à Flash.
Electron est open-source, basé sur des technos open-source, rien n'empêche à quiconque de contribuer au projet et de nettoyer le code de ses parties inutiles.
@mp_
Ok, mais si l'architecture est mauvaise, ce n'est pas en "nettoyant le code" qu'on va aller très loin. D'autant plus que là l'idée c'est qu'electron utilisé le noyau de Chrome, et à moins d'en faire un fork et de l'adapter à cette utilisation (dans Électron donc), il restera fait pour autre chose (un navigateur web) et ne pourra être rendu plus performant qu'un certain point.
"Ne terminons pas sur une note négative. Comme tout projet logiciel, Electron est appelé à évoluer et ses concepteurs peuvent se concentrer sur l’optimisation des performances. Par ailleurs, il devrait aussi profiter des optimisations menées depuis plusieurs années par Google sur Chrome."
Dès la première version, Chrome était censé être le navigateur le plus optimisé qui soit.
Depuis presque 10 ans, on a régulièrement droit à des annonces d'optimisations fracassantes.
Combien d'années et combien de versions faudra-t-il encore pour que les annonces de Google ne soient plus prises pour argent comptant ?
@Nicolas
Merci beaucoup pour l'article très intéressant.
Il n'empêche, Chromium a réussi (faire adopter sa plateforme web multiplateforme par un plus grand nombre en tant que brique de base) là où d'autres ont "échoué" (je pense notamment à XulRunner pour Mozilla/Firefox, la JVM qui n'a pas su proposer une plateforme cohérente avec toutes ses briques externes). De plus, proposer une plateforme web alors que la norme de scripting web de base est très vieillotte et usine à gaz, c'est à chaque fois une prouesse et c'est une des raisons qui a plombé Flash.
Si XUL avait repris la description d'interface en XML de gtk au lieu de développer sa propre version on n'en serait peut-être pas là.
@vince29
Je pense qu'il y a surtout eu à l'époque un problème de gouvernance et que le "code spaghetti" des navigateurs Mozilla était une plaie.
Toutes ces apps peuvent elles s'installer sur Chrome OS, et s'affranchir du noyau de Chrome à chaque fois?
Ce serait pas mal non?
« Les apps Electron ont l’apparence d’interfaces natives »
Mouais. Juste une apparence de surface, hein.
Parce qu’il n’y a pas besoin d’utiliser une telle application bien longtemps pour se rendre compte qu’on a affaire à un site web déguisé en application. L’intégration avec Mac OS (et donc les autres applications) est quasi-nulle.
Regarde les API electron et tierces avant de dire des bétises.
@ lord danone : « Regarde les API electron et tierces »
Mais encore ?
« avant de dire des bétises. »
Jusque là, je n’en ai encore écrit aucune. ;-)
J’ai juste décrit le constat fait à l’usage des quelques applications basées sur Electron que j’ai testées.
Electron permet une integration aux OS tres tres proche du natif, encore faut il que les devs aient pris la peine de le faire.
"L’intégration avec Mac OS (et donc les autres applications) est quasi-nulle." --> Ca c'est la bétise, c'est une généralisation par rapport à tes expériences, la réalité est différente
Pages