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

@ lord danone : « Electron permet une integration aux OS tres tres proche du natif »

Bon, merci pour l’info (parce que franchement, ça ne saute pas aux yeux, en particulier à cause du principe même sur lequel repose ce machin). Le jour où j’aurai du temps pour ça, j’irai vérifier ce qu’il en est, promis ! :-)

« encore faut il que les devs aient pris la peine de le faire. »

Notons que s’il faut une dose conséquente de boulot pour soigner l’intégration à chaque plateforme, ça va à l’encontre de ce qui attire un grand nombre de développeurs vers ce genre de solution multiplateformes.
C’est le principal problème de ces machins multiplateformes.

« Ca c'est la bétise, c'est une généralisation par rapport à tes expériences, la réalité est différente »

Ben écoute, puisque tu sembles si bien maîtriser ce sujet, pourquoi est-ce que tu ne me donnerais pas un exemple d’une application basée sur Electron et qui a un bon niveau d’intégration avec Mac OS ? Ça te ferait gagner du temps dans ta démonstration que la réalité est différente de ce que j’ai pu en percevoir jusque là, et pour ma part, je ne te cache pas que je serais plus facilement convaincu de cette façon-là. Merci d’avance. ;-)

avatar lord danone | 

Je n'ai pas d'app en particulier mais va juste voir la liste de l'API 'officielle' d'electron https://github.com/electron/electron/tree/master/docs, il y a de quoi faire :)

avatar BeePotato | 

@ lord danone : « Je n'ai pas d'app en particulier »

Ah ben ça ne m’aide pas !
Donc tu m’accuses de ne faire que généraliser à partir de mon expérience, mais toi apparemment tu ne fais même pas reposer tes affirmations sur une quelconque expérience. C’est très loin d’être convaincant.

« mais va juste voir la liste de l'API 'officielle' d'electron https://github.com/electron/electron/tree/master/docs, il y a de quoi faire :) »

J’ai justement passé du temps cette nuit à aller la voir, la doc des API, poussé par la curiosité que tu avais suscitée. Et je n’y ai rien trouvé qui permette une intégration poussée avec Mac OS.

Pour ce qui est du niveau minimum de l’intégration (respecter le fonctionnement basique de l’interface utilisateur de l’OS), ça ne se voit évidemment pas dans les API, puisque c’est quelque chose qui doit être géré directement par le framework, de manière transparente pour les développeurs (sinon, quel serait l’intérêt d’un framework multiplateformes ?). Et c’est cette partie-là dont on peut constater, en essayant quelques applications basées sur Electron, qu’elle est plutôt incomplète (sans être aussi catastrophique que ce qu’on a pu voir par le passé avec d’autres machins multiplateformes, certes).

avatar lord danone | 

Electron n'a pas pour vocation a créer différentes UI pour chaque OS, et il n'y a rien de choquant à ca : n'importe quelle application peut avoir une UI unique qui 'fonctionne' très bien sur windows/max/linux. C'est le principe du site web, que tu sois sur linux mac ou windows, tu as la même interface et ca marche très bien comme ça, pourquoi faire 3 versions d'une même interface alors qu'une seule marche très bien? Va voir les apps discord et spotify par ex.
Si tu veux vraiment t'amuser a faire du macOS like, ils y a des UI kit genre http://photonkit.com/ ...

Pour tout le reste, electron permet d'accéder à la majorité des fonctionnalités de chaque OS, sur mac os ca sera le dock, la barre de menu, les notifications systemes, le clipboard, les events systeme, le dialogue entre différents process de ton appli, les préférences systeme, les boites de dialogues systemes, le positionnement et la taille des fenetres, ouvrir des fichiers dans le browser par défaut, mettre des fichiers a la corbeille, capturer l'écran,... + tout ce que te permet NodeJS...

avatar softjo | 

Le natif n'est pas toujours meilleur. Suffit de voir la performance de Number avec des csv assez gros (performance tellement mauvaise que c'est inutilisable)

Ou iTunes... Si seulement iTunes utilisait électron.... On aurait une bombe à la place de ce truc pas fluide même sur les derniers mac.

3e exemple: l'affichage grille du dock qui n'affiche pas 24fps avec 50 elements...

avatar lord danone | 

Complètement pas d'accord avec cet article.
Oui electron est un gouffre à mémoire si le code executé est lui même un gouffre à mémoire. Je developpe une app electron depuis quasi 1 an, et quand je vois que mon app utilise trop de mémoire, je fais comme tous les dev, je profile mon code et dans 100% des cas la cause du leak est que j'ai codé comme une daube. Encore hier, je suis passé de 960Mo de ram occupée en pic à 480Mo en changeant un algo...

Quand mon app rame, je profile mon code et dans 100% des cas c'est mes algos qui sont à chier et/ou les librairies JS tierces qui sont toutes pourries.

Si je ne me posais pas la question de savoir pourquoi mon app consomme trop de mémoire et ou rame, oui mon app serait un gouffre à mémoire et a cpu. Mais non, ca ne serait pas la faute d'electron, c'est la faute du dev.

avatar oomu | 

Oui, bref la vie habituelle avec les middlewares multiplateforme

Je garde vos commentaires pour les reposter lors de la prochaine fois (prochain middleware permettant d'économiser en temps de portages et adaptation pour faire du boulot de fauché)

Par ailleurs le meme propos et la plupar de vos commentaires auraient été valides pour une discussion d'il y a 15 ans à propos de QT.

Ou JAVA (sur le bureau, hahahahahaaarr gargl) bien évidemment.

avatar lord danone | 

A la différence qu'electron n'est qu'un navigateur+serveur packagé sous forme d'une app. A chosir un middleware, je prefere Safari/Firefox/Chrome + node plutot qu'un java/QT+jee

avatar oomu | 

nous avons ici un vrai débat.

je n'imagine pas une seconde un DAZ Studio en javascroupt.

avatar lord danone | 

D'où le fait que la comparaison est foireuse et que le terme middleware est trop large pour comparer electron a java/qt. Un navigateur est (a ma connaissance) le meilleur middleware pour executer une web app javascroupt mais bon de là à appeller un navigateur compilé en natif un middleware je suis pas hyper convaincu

avatar blopi4 | 

Le vrai développement multi plateforme (mobile) c'est Xamarin ;)

avatar marc_os | 

Pour faire tourner des web Apps rien de mieux qu'un "bête" navigateur !!

avatar denmakesmusic | 

J'ai une appli développée en JavaFX : 15Mo et une autre équivalente avec Electron : 130Mo.

Pour moi Java est la plateforme qui répond à la promesse du développement unique ou quasi, avec des performances honnêtes voir très bonnes si on ne fait pas n'importe quoi. Seul le lancement est pénalisé à cause de la JVM mais cela va peut-être s'améliorer grâce à Java 9.
En tout cas Java+JavaFX est un ensemble cohérent, assez mature et léger alors que le développement Javascript est en perpétuel changement ce qui rend les choix de technos difficiles. Par ailleurs la documentation des frameworks Javascript laisse souvent à désirer tandis que l'écosystème Java est de très bonne qualité.

avatar MaksOuw | 

"Et il ne faut pas compter sur certaines fonctions importantes, comme la coloration syntaxique"

Ce qu'il faut pas entendre... La coloration syntaxique est présente hein. Puis sinon, c'est des plugins à installer, je vois pas vraiment le problème sur un éditeur "hackable".

Mais sinon, malheureusement, Atom a tendance à freeze un peu trop à mon gout. Il faudrait vraiment qu'ils arrivent à optimiser ça, mais c'est du JS, et optimiser du JS... :( (bon puis il faudrait que je change de machine au boulot, ça serait surement mieux aussi)

avatar pol2095 | 

Que Chrome soit une daube, c'est sur, si on le laisse tourner trop longtemps, il explose la mémoire.

Pages

CONNEXION UTILISATEUR