Développement : Electron est-il le nouveau Flash ?

Nicolas Furno |

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.

Cliquer pour agrandir

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.

Quelques apps parmi toutes celles qui exploitent Electron. Cliquer pour agrandir

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.

Slack peut vite monopoliser beaucoup de ressources… (image Marc Edwards). Cliquer pour agrandir

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.

La prochaine version d’Atom se lancera beaucoup plus rapidement que la précédente. Cliquer pour agrandir

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.

Atom s’est amélioré sur ce point, mais les gros fichiers lui font toujours peur. Cliquer pour agrandir

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.

avatar ovea | 

Un logiciel auteur … Arg 😋

avatar ovea | 

OCaml !

avatar Hasgarn | 

Ce n'est pas demain qu'on se passera des technos natives, donc 😊

avatar RyDroid | 

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.

avatar iGeek07 | 

É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" 🙄)

avatar pecos | 

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.

avatar valcapri | 

@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.

avatar pecos | 

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...

avatar iGeek07 | 

@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.

avatar frankm | 

Ca ressemble aux applications HTA exécutées par un Internet Explorer OPEN BAR mshta.exe. Ca a donné le fameux virus ILOVEYOU

avatar marc_os | 

@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 !

avatar BeePotato | 

@ 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 ».

avatar RedMak | 

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 !

avatar MisteriousGaga | 

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 ?

avatar Un Type Vrai | 

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...

avatar BeePotato | 

@ 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. ;-)

avatar Un Type Vrai | 

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...

avatar oomu | 

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.

avatar fte | 

@oomu

S'il y a bien une chose qui ne m'a jamais fait phantasmer, c'est bien CORBA. Ah ça non.

avatar BeePotato | 

@ oomu : « Fut un temps, j'ai fantasmé sur openstep, et aussi Corba, oui madame. »

Chacun ses perversions… :-)

avatar BeePotato | 

@ 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.

avatar oomu | 

"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 !

avatar BeePotato | 

@ oomu : « Violemment NON ! »

Ben pourtant si.

avatar oomu | 

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.

avatar Mike Mac | 

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.

Pages

CONNEXION UTILISATEUR