Faut-il utiliser Electron pour le développement d'applications de bureau ?
Quels sont ses avantages et inconvénients ?
Le 2017-10-07 20:43:29, par Michael Guilloux, Chroniqueur Actualités
« 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. »
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 :
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 ?
Pensez-vous qu’Electron (ou la pile Web) est adapté pour développer de bonnes applications de bureau ?
Quels sont ses avantages et inconvénients ? Partagez votre expérience
« 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. »
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 ?
-
micka132Expert confirmé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...le 09/10/2017 à 11:32 -
UtherExpert éminent séniorAu contraire ça va faire plus de travail inutile à maintenir du code généralement plus laxiste.
Parce qu'il faut pas croire que les développeurs C/CPP/Java sont forcément des ringards dépassés incapable de faire du JS, c'est juste qu'ils savent le bordel que c'est et préfèrent s'en passer quand c'est possible.le 12/10/2017 à 14:15 -
GunthaMembre expérimenté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âchisfar from that, I don't think anyone disagrees that the web is a mess
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
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...le 09/10/2017 à 9:58 -
kedareMembre chevronné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 )) :le 09/10/2017 à 15:35 -
GordonFreemanMembre éclairé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.le 09/10/2017 à 15:49 -
kedareMembre chevronné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é.- 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 09/10/2017 à 16:06 -
GilbertLatrancheMembre avertiEn tant que développeur : le problème est que les ressources d'une machine ne sont pas infinies et qu'il y a une limite à ne pas franchir quand un développeur veut se simplifier la vie.
Si certains veulent se foutre de la gueule de leurs utilisateurs, c'est leur droit, perso je cautionne pas.
En tant qu'utilisateur : lancer toute une instance de Chromium par application Electron, surtout si c'est pour gérer une todolist, pour moi c'est niet. Quand je télécharge une appli desktop, je m'attends à un minimum de performances, c'est à dire pas de phagocytage de la mémoire, du ventilo ou du CPU par des logiciels qui ne devraient pas le faire. Histoire aussi, de laisser un peu de place aux autres logiciels qui cohabitent sur la machine.
Je m'attends aussi à ce que le développeur à l'origine du produit soit un peu compétent. Quand je vois Slack Desktop qui lance l'équivalent d'un Chromium par chan, clairement, ça me met pas en joie.le 10/10/2017 à 14:40 -
BouskRédacteur/ModérateurDiscord a beau être une success story (j'ai loupé le hype train de ce machin), c'est typiquement une utilisation wtf : de ce que je vois de screenshots, n'importe quel lib UI de n'importe quel langage fait aisément pareil.
Donc : pourquoi diable faire ça en JS pour le client lourd quand n'importe quel choix de langage natif ferait mieux ? Et surtout, pourquoi devoir lancer Chromium et tuer les perfs (coucou les mobiles si la version mobile utilise ça aussi) pour.. euh.. çale 10/10/2017 à 16:40 -
micka132Expert confirmé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?
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.le 09/10/2017 à 9:49 -
UtherExpert éminent séniorPour 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).le 09/10/2017 à 13:42