Faut-il utiliser Electron pour le développement d’applications de bureau ?

Faut-il utiliser Electron pour le développement d’applications de bureau ?
Quels sont ses avantages et inconvénients ?

« Dites non à Electron ! », suggère Renato Athaydes, un développeur logiciel travaillant dans une entreprise technologique privée. C’est sa réponse à de récentes discussions dans des forums de programmation sur Electron et son impact sur le monde du développement d’applications de bureau.

« Si vous ne connaissez pas Electron, il s'agit essentiellement d'un navigateur Web (Chromium) qui héberge seulement votre application Web... comme s'il s'agissait d'une application de bureau (non, ce n'est pas une blague) », dit-il. « Cela vous permet d'utiliser la pile Web pour développer des applications de bureau multiplateformes. »

http://www.developpez.com/public/ima...s/electron.jpg

Ce qu'il faut retenir, c'est que le framework Electron vous permet d'écrire des applications de bureau multiplateformes en utilisant JavaScript, HTML et CSS. Il est basé sur Node.js et Chromium et est utilisé par l'éditeur Atom, mais également de nombreuses autres applications. Parmi ces dernières, on peut citer :

• Visual Studio Code, l'éditeur de code open source développé par Microsoft ;
• Slack, l'application de messagerie pour les équipes ;
• Nuclide, un IDE ouvert pour le développement Web et mobile natif, construit au-dessus d'Atom ;
• l'application de bureau de WordPress ;
• l'application de bureau de Twitch ;
• l'application de bureau de GitHub ;
• etc.

Vous trouverez en effet un nombre croissant d'applications de bureau modernes qui utilisent ce framework. C'est ce que note d'ailleurs Renato Athaydes, mais pour lui, c'est horrible de penser qu'on peut faire de meilleures applications de bureau en utilisant des technologies du Web.

« La plupart des nouvelles applications de bureau "branchées" de nos jours sont construites sur Electron », dit-il en reconnaissant après tout que c'est remarquable. « Nous avons écrit des applications de bureau pendant des décennies. Le Web, par contre, a vraiment commencé il y a moins de 20 ans, et la plupart du temps, il n'a été utilisé que pour servir des documents et des gifs animés, et non pour créer des applications à part entière, pas même les plus simples. »

« Penser que la pile Web serait utilisée pour créer des applications de bureau il y a 10 ans était impensable. Mais nous y sommes, en 2017, et beaucoup de gens intelligents pensent que Electron est une excellente idée ! » Pour lui, cela n'est pas pour autant le résultat de la supériorité de la pile Web sur les frameworks d'interfaces de bureau, pour le développement d'applications. « Loin de là, je ne pense pas qu'il y ait une seule personne qui ne soit pas d'accord sur le fait que le Web est un gâchis », a-t-il souligné.

Pour ironiser, en faisant allusion aux applications qui utilisent Electron, il affirme que « si les gens préfèrent livrer un navigateur Web complet avec leurs applications afin qu'ils puissent utiliser d'excellents outils tels que JavaScript pour les développer, il y a vraiment quelque chose qui ne va pas. »

C'est en fait là l'un des principaux reproches faits à Electron. Indépendamment de la question de savoir si la pile HTML + JavaScript + CSS est bonne pour les applications de bureau, l'un des points qui dérangent le plus à propos d'Electron est qu'il va empaqueter un runtime Web complet dans chaque application, même si un runtime convenable existe déjà sur le système d'exploitation. Chromium comprend plus de 20 millions de lignes de code et il semble que chaque application Electron va empaqueter une copie de cette énorme base de code sous forme de binaire. Cela aura pour conséquence de grossir la taille de votre application et créer un gaspillage de mémoire.

Il existe pourtant selon Renato Athaydes de meilleures alternatives à Electron pour le développement d'applications de bureau. Si cela ne vous pose pas de problèmes d'avoir différentes équipes pour chaque système d'exploitation populaire, il pense alors à Windows Presentation Foundation (WPF) sur Windows et AppKit sur macOS.

Mais comme l'idée derrière Electron c'est de pouvoir développer des applications de bureau multiplateformes, il estime que les concurrents réels et meilleures alternatives à Electron sont les frameworks multiplateformes, notamment GTK+, Qt et JavaFX.

GTK+ est un toolkit permettant de créer des interfaces utilisateur graphiques. GTK + est multiplateforme et dispose d'une API facile à utiliser, ce qui permet d'accélérer le temps de développement. Il est écrit en C, mais a été conçu de manière à supporter un large éventail de langages, pas seulement C/C ++.

Qt est un framework de développement d'applications multiplateformes, pour desktop, l'embarqué et le mobile. Les plateformes prises en charge incluent Linux, OS X, Windows, VxWorks, QNX, Android, iOS, BlackBerry, Sailfish OS et bien d'autres.

Son choix est toutefois JavaFX qui avec la JVM, selon lui, est parfait pour développer des applications de bureau rapides et responsives.

Source : Billet de Renato Athaydes

Et vous ?

:fleche: Pensez-vous qu’Electron (ou la pile Web) est adapté pour développer de bonnes applications de bureau ?
:fleche: Quels sont ses avantages et inconvénients ? Partagez votre expérience

Je crois que ce billet est un peu à côté de son sujet. Oui, je peux parfaitement comprendre le succès d'Electron: pour des équipes qui développent des applis Web (Twitch, GitHub, Wordpress,...), c'est l'outil idéal pour proposer aux utilisateurs une alternative "desktop" à moindre frais. D'un côté les développeurs restent sur les mêmes technologies/langages, et de l'autre les problèmes de portabilité sur différentes plateformes (windows, linux, etc...) sont délégués à un tiers (Chromium). C'est tout bénéf'.

Quand l'auteur cite JavaFX, c'est d'ailleurs la même logique qui est à l'oeuvre: grâce à la JVM, les développeurs "sous-traitent à Oracle" tout ce qui concerne les problèmes de plateforme.

Du coup, proposer GTK+ ou Qt comme alternative à Electron, je ne trouve pas ça pertinent: cela nécessiterait de recruter de nouveaux développeurs, de faire attention à bien gérer toutes les plateformes, voire à en laisser tomber certaines, et à maintenir un code source sans base commune avec l'appli web de départ.

Bref, GTK+, Qt, JavaFX et les autres, ça peut avoir du sens pour des applications nativement "desktop", mais dans les exemples cités par l'auteur on parle de migrer des applis web. Et dans ce cadre, je pense qu'Electron est parfaitement légitime.

Et ce n'est même pas une idée neuve: Adobe propose déjà Air depuis 2008, pour créer une version "desktop" d'une appli Flash.

Comme le posteur précédent, je ne vois pas du tout le rapport entre WPF, QT et autres langages et Electron...

Electron permet d'avoir une application de bureau très rapidement à partir d'une application Web existante.

Très bon exemple avec Discord.

Citation:

---

Envoyé par nnovic

D'un côté les développeurs restent sur les mêmes technologies/langages, et de l'autre les problèmes de portabilité sur différentes plateformes (windows, linux, etc...) sont délégués à un tiers (Chromium). C'est tout bénéf'.

---

C'est je crois une erreur de croire que parce que l'on reste sur du html/js/css on est sur du réutilisable en terme de compétence. Tout ça c’était avant! Le fameux JS est assez inutile, en tout cas pas plus utile qu'il ne l'a été pendant 20 ans. En effet pour arriver à un minimum de productivité il faut passer par un des innombrables frameworks qui changent chaque semaine...Elles sont bien utiles les compétences d'angular 1, alors que maintenant faut passer sur du React (ouai désolé ca doit faire 6 mois que je me tiens pas au courant doit y avoir autre chose maintenant).
Tiens pour le fun https://colorlib.com/wp/javascript-frameworks/ top 23 framework JS. On parie qu'en 2018 la moitié sont dépassés ou abandonnés?

Citation:

---

Envoyé par nnovic

Quand l'auteur cite JavaFX, c'est d'ailleurs la même logique qui est à l'oeuvre: grâce à la JVM, les développeurs "sous-traitent à Oracle" tout ce qui concerne les problèmes de plateforme.

---

C'est ça qui me fait penser qu'il n'y a rien de logique derrière cette explosion du web...Java ça fait 20 ans que ça promet la même chose, Flash également. A mon avis la seul différence c'est Google qui pousse derrière avec un lobby de malade.

Citation:

---

Loin de là, je ne pense pas qu'il y ait une seule personne qui ne soit pas d'accord sur le fait que le Web est un gâchis

---

Je trouvais la citation un peu chelou et radicale, alors j'ai regardé le billet original:

Citation:

---

far from that, I don't think anyone disagrees that the web is a mess

---

Là en effet, personne ne discutera le fait que le web, c'est le bordel.

Et sans même parler de JavaFX, souvent pour shipper des applis Java on recommandait de fournir la JVM avec, au cas où le client ne l'avait pas installé lui-même, et pour être sûr que le client en avait une compatible, donc le problème est loin d'être nouveau :mrgreen:

Dans le fond, je suis d'accord que c'est mieux d'avoir une équipe capable de gérer chaque plate-forme, surtout si on a de gros besoins d'intégration à la plate-forme ou de performance, mais si une appli web fait le boulot...

J'ai utilisé Electron personnellement pour deux projets persos. Un logiciel de snippets et un autre qui me permet de créer des raccourcis clavier globaux.

Mon avis

+ Electron est LARGEMENT suffisant pour écrire une application qui n'a pas besoin de hautes performances.
+ Pour un projet perso, c'est beaucoup plus efficace de créer l'UI dans un langage connu et maîtrisé que d'essayer autre chose. Je code aussi en Java et C/C++ mais je les réserve pour les logiciels où la performance est le critère principal. Pour les UI, mon opinion est pour React+ES6.
+ Il est possible d'écrire des parties de l'application en natif et de l'utiliser dans Electron.

- Electron consomme énormément de mémoire vive pour l'usage qu'on en a. J'utilise Rambox qui est écrit en Electron et il prend 1Go de mémoire vive avec une dizaine d'onglets ouverts.
- C'est évidemment moins performant qu'une app native mais ce serait le cas pour n'importe quel langage natif. Personne n'est choqué quand une app est écrite en Python, mais quand c'est du JS oh lala !

J'ai essayé Qt avant Electron, j'en ai eu une très mauvaise expérience. Si je dois souffrir 4x plus pour un gain théorique de performances de 10% pour l'UI, je ne vois pas l'intérêt.

Javascript + HTML est excellent pour créer des UI. Ne pas s'en servir "parce que c'est Javascript, c'est pour le Web" c'est un biais cognitif, rien de plus.

Pour conclure

Javascript a toujours été un langage avant-gardiste. Il a toujours essayé de nouvelles choses, a toujours été violemment critiqué, et s'en est toujours sorti.
Electron va évoluer et régler ses problèmes, comme React l'a fait, comme Node.js l'a fait, comme JS vanilla lui-même l'a fait.

Et si vous êtes toujours du côté des anti-JS, pensez à ceci :

Pièce jointe 318015
(source : https://www.slideshare.net/BrendanEi...et_on_JS_First)

Nous sommes simplement à l'étape "They said it's stupid to use it for Desktop apps"

Citation:

---

Envoyé par xurei

Et si vous êtes toujours du côté des anti-JS, pensez à ceci :

---

La question n'est pas d’être pro ou anti, c'est d'essayer de voir les avantages de telle ou telle techno. On peut changer ton petit dessin en remplaçant JS par Assembleur, ou Brainfuck.
JS ne fait rien tout seul, comme n'importe quel langage, et ce sont des gens qui décident de créer des outils pour le faire fonctionner dans tel ou tel environnement.
Aujourd'hui on veut nous faire croire cette nieme chimère de LA solution cross plateforme qui va résoudre n'importe quel problème est la bonne.
Ben moi j'y crois pas, même si y a un gus qui à fait un OS en JS, ça reste un beau défi de fou furieux, mais ça ne va pas plus loin.
Tout est faisable, dans n'importe quel langage...

Nan sans rire... ce monsieur affirme utiliser JavaFX pour des applications desktop ? C'est juste ridicule. A moins qu'il bosse chez tableurSoftInc je vois pas trop ce qu'il peut faire de bien en javaFX... c'est juste bon à faire des applicatons de gestion.

JavaFX est a l'abandon total à se demander si Oracle savent qu'ils possède ce truc.

Swing super mais malheureusement niveau esthétisme on a vu mieux...

Qt : ok la on se rapproche de quelque chose de pas mal et au moins on peut accéder de façon naturelle au hardware car bon c'est le but d'une application native généralement. Dans le cas contraire on a gentillement des siteweb/webapp pour a peu près tout faire.

Ahhh mais attends c'est pas justement pour ca qu'électron est la ? Comme ça on code la webapp et on l'intègre dans une appli "semi native" qui nous permet de ne coder qu'une fois l'appli et d'y ajouter 2 ou 3 features comme les notifications intégrées à l'OS ?


Electron sa force c'est ça ! Code once run everywhere ! Mais ça fait peur aux vieux Senior JAVA qui ont toujours refusé de s'ouvrir au monde et d'apprendre autre chose que java...

Faut sortir de votre bulle les gars... Java c'est génial niveau backend mais il existe d'autres trucs hein :p

Citation:

---

Envoyé par nnovic

Bref, GTK+, Qt, JavaFX et les autres, ça peut avoir du sens pour des applications nativement "desktop", mais dans les exemples cités par l'auteur on parle de migrer des applis web. Et dans ce cadre, je pense qu'Electron est parfaitement légitime.

---

Pour Github, Wordpress ou Twitch, ok.
Mais parmi les applications citées il y a Atom et VS Code et pour le coup c'est le genre d'applications qui n'ont pas particulièrement intérêt à employer des technologies Web, d'ailleurs, les performances s'en ressentent (surtout pour Atom).

Citation:

---

ce monsieur affirme utiliser JavaFX pour des applications desktop ? C'est juste ridicule.

---

Tout a fait d'accord. Le but est toujours de développer une application au bon rapport performance/maintenabilité.
Pour une application ayant de gros besoin de ressources il vaux mieux se tourner vers Qt ou Gtk+ mais sinon Elektron est très bien. JavaFX est juste pas maintenable car Oracle n'y à jamais mis les ressources nécessaire pour la rendre performante donc il n'y a pas de talents et la technologie est en perte de vitesse.

Le choix que je trouve assez peu judicieux c'est utiliser JS pour Atom car un IDE a de gros besoin de ressource. Cela se comprenait au départ pour un éditeur de texte. Mais pour un IDE...

Personnellement par défaut j'évite les applications faites avec Electron pour la simple et le bonne raison que 90% sont des usines a gaz, des gouffres en CPU et mémoire.

Le soucis c'est que les développeurs JS ne sont pas des développeurs de client lourds ou de GUI, 99% ne s'occuperont pas de l'optimisation CPU / Mémoire (Faut juste que ca soit joli et vite fait)

Aussi il ne faut pas oublier que c'est généralement totalement incompatible avec les mesures d'accessibilités comme les lecteurs brailles ou autre dispositifs. (Comme ce ne sont ni des composants natif ni un browser complètement configurable)

Aller un petit cadeau, la consommation en mémoire de Slack qui utilise Electron (Un client de messagerie très populaire en entreprise... ( malheureusement )) :

Pièce jointe 318145

Bonjour,

Quand je vois certaines critiques sur JavaFX :
- JavaFX est a l'abandon total à se demander si Oracle savent qu'ils possède ce truc.
- JavaFX pour des applications desktop ? C'est juste ridicule.

Je me dis que certaines personnes parlent sans savoir...
JavaFX (je parle de la version 2) évolue toujours et est fait pour du client lourd.

La première version était juste horrible. La 2ème (AMHA) est juste fabuleuse en terme de conception d'IHM. Ça réunit les avantages que j'ai pu voir dans différentes techno (Flex, JS, Swing, etc)

Malheureusement il est clair que ce ne sera jamais le trend de demain vu que le client lourd n'a plus la cote de nos jours.

JavaFX est un très bon système de GUI. Je pense qu'il a récupéré la mauvaise réputation de Swing. Et bon la premiere version de JavaFX n'était pas terrible non plus, mais la v2 est bien meilleur.

Il ya aussi la réputation de lourdeur de Java... Mais je pense pas que ca soit pire qu'Electron, surtout avec Java 9 et le nouveau système de modularité.

Citation:

---

- C'est évidemment moins performant qu'une app native mais ce serait le cas pour n'importe quel langage natif. Personne n'est choqué quand une app est écrite en Python, mais quand c'est du JS oh lala !

---

Le problème c'est pas le langage c'est le GUI tooolkit, entre une application Python + Gtk/Qt/Wx ou JS + Electron je choisit de loin Python (Pour la meilleur experience utilisateur et le peu de resources utilisées)

Citation:

---

Envoyé par sbeex

Nan sans rire... ce monsieur affirme utiliser JavaFX pour des applications desktop ? C'est juste ridicule. A moins qu'il bosse chez tableurSoftInc je vois pas trop ce qu'il peut faire de bien en javaFX... c'est juste bon à faire des applicatons de gestion.

JavaFX est a l'abandon total à se demander si Oracle savent qu'ils possède ce truc.

Swing super mais malheureusement niveau esthétisme on a vu mieux...

Qt : ok la on se rapproche de quelque chose de pas mal et au moins on peut accéder de façon naturelle au hardware car bon c'est le but d'une application native généralement. Dans le cas contraire on a gentillement des siteweb/webapp pour a peu près tout faire.

Ahhh mais attends c'est pas justement pour ca qu'électron est la ? Comme ça on code la webapp et on l'intègre dans une appli "semi native" qui nous permet de ne coder qu'une fois l'appli et d'y ajouter 2 ou 3 features comme les notifications intégrées à l'OS ?


Electron sa force c'est ça ! Code once run everywhere ! Mais ça fait peur aux vieux Senior JAVA qui ont toujours refusé de s'ouvrir au monde et d'apprendre autre chose que java...

Faut sortir de votre bulle les gars... Java c'est génial niveau backend mais il existe d'autres trucs hein :p

---

J'ai vraiment hésité à te répondre :mur: .
Bref, je te laisse ce lien

Le problème que je vois est que d'un côté on a le monde du web avec des centaines de projets qui naissent et meurent chaque jour, et d'un autre côté on a le monde du desktop où très peu de projets desktop GUI sérieux existent et sont propres...

Je trouve JavaFX tout à fait adapté au desktop, surtout avec Java derrière, et grâce à des projets comme TornadoFX (en Kotlin) ou MaterialFX (lib Material design pour JavaFX), c'est un framework dans lequel il devient très facile d'avoir de très propres rendus.

Alors forcément, ça demande plus de rigueur et de temps d'apprentissage que cloner le dernier angular-quickstart-template et faire un coup de "npm install && grunt build && electron start dist/main.js" mais le résultat obtenu est très facilement beaucoup plus performant, stable et maintenable.

Surtout que même pour de petites apps, Electron est extrêmement lourd et ne justifie pas grand chose, surtout à cause de la complexité des stacks full-js derrière.

Une bonne lecture là dessus: https://josephg.com/blog/electron-is...r-the-desktop/

Le client lourd en Java, toute une histoire. :mouarf: Ce sera sans moi en tout cas, JavaFX ou pas.

Perso j'ai Discord qui tourne sous Electron, et il prend pas un pet de mon processeur quand je ne l'utilise pas. 19Mb de RAM, avec la gestion de la voix et de multiples canaux.

Donc bon, l'exemple bien ciblé qui prouve et généralise l'avis (négatif) de l'auteur sur Electron (ce que je ne fais pas avec mon exemple, c'est juste un contre-exemple), très peu pour moi aussi. ;)

Je trouve qu'une plateforme JS comme Electron répond a un besoin clair : celui de pousser ou dupliquer une application Web en application lourde multi-plateforme, en déconnecté ou non, d'ailleurs. Et il le fait déjà pas mal du tout, alors que peu d'autres frameworks y arrivent (ni Microsoft, ni Java ne savent le faire en multi-plateforme...). Et Electron va continuer à s'améliorer j'espère.

Citation:

---

Envoyé par alves1993

J'ai vraiment hésité à te répondre :mur: .
Bref, je te laisse ce lien

---

Bof, à première vue ce ne sont pas franchement des applications "grand public", quand même...

Autant je trouve ça sympa dans l'idée, autant je suis pessimiste sur son utilisation..
Si c'est juste "on a une team de dev web et on veut faire un petit truc desktop rapide", ok.
Si c'est juste parce que "javascript est plus simple et il est plus simple de recruter" ou "on connait que js alors on l'utilise partout", c'est vraiment dommage.
Vouloir faire un client lourd avec cette techno est pour moi tout aussi stupide que de vouloir faire du web avec C++. Ca marche, mais c'est loin d'être un choix intelligent pour autant.
Vouloir absolument utiliser js parce que c'est la seule stack que l'on connait... c'est rogner un cube pour le faire entrer dans un cercle. Faut adapter la techno au projet, non le projet à la techno. Et en ce sens js est de plus en plus n'importe quoi.
Quant à la portabilité, elle dépendra toujours du portage de l'engine derrière, donc c'est un faux problème.

Electron n'est pas une idée nouvelle, Intel avait déjà proposé cela il y plusieurs années au début de HTML5.

Empaqueter une appli web dans un environnement cohérent et figé est une nécessité en entreprise.

Je sais, c'est moche, mais il semble impossible de s'en passer car:
- les navigateurs suivent leurs propres chemin et cassent régulièrement les applis web existantes
- on n'arrive jamais à trouver un navigateur unique compatible avec toutes les applis

On en arrive à créer des micro navigateurs web "une page" et sans historique ni barre d'adresse (ni de retour arrière) avec par exemple Qt ou un Firefox figé en version.
Pour l'intranet on les empâche d'aller sur internet en ne renseignant pas le proxy (pour éviter toute utilisation d'un vieux navigateur sur internet)

Ca permet:
- de garantir le fonctionnement présent sur le poste client
- de garantir le fonctionnement futur sur le poste client (la durée de vie de l'appli web suit la durée de vie de cette version du mini navigateur).

Je considère actuellement que le fonctionnement d'une appli web ou intranet dans le navigateur de l'utilisateur est un mode dégradé fortuit temporaire.

Bref, je pense qu'en appli HTML5 doit être livrée avec son lecteur.

Maintenant, bien que je partage le point de vue de l'auteur sur l'immense gâchis de ressources que sont les applis HTML5 (mémoire et CPU), sur le poste de travail c'est rarement un très gros problème.
Donc on peut souligner les avantages en réactivité de Java ou .Net ou Qt sur les interfaces graphiques, mais le HTML5 a l'avantage d'être très répandus, et de faire que l'utilisateur se sent en confiance car ça ressemble à ce qu'il connaît.

D'ailleurs, mes dernières applis Java utilisaient le moteur HTML intégré pour présenter à peu près tout.

Citation:

---

Envoyé par blbird

Perso j'ai Discord qui tourne sous Electron, et il prend pas un pet de mon processeur quand je ne l'utilise pas. 19Mb de RAM, avec la gestion de la voix et de multiples canaux.

---

C'est cela oui.

https://i.imgur.com/zfGuTWP.png

Fun fact : je ne suis même pas encore loggé.