Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Michael Guilloux

315PARTAGES

13  0 
« 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 :

  • 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 ?

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 12/10/2017 à 14:15
Citation Envoyé par setni Voir le message
Heu, est-ce que cet article ne serait pas uniquement un coup de gueule contre cette petite révolution du dev software qui consiste à remplacer les C/CPP/Java par du JS??

Quand on y pense, si toutes les boites se mettent à dev en electron, pas mal de devs (ceux qui ont la nausée en voyant du JS) vont se retrouver au chômage...
Au 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.
13  1 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 09/10/2017 à 11:32
Citation Envoyé par xurei Voir le message
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...
11  0 
Avatar de Guntha
Membre éprouvé https://www.developpez.com
Le 09/10/2017 à 9:58
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:

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

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...
7  0 
Avatar de kedare
Membre expérimenté https://www.developpez.com
Le 09/10/2017 à 15:35
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 )) :

7  0 
Avatar de GordonFreeman
Membre confirmé https://www.developpez.com
Le 09/10/2017 à 15:49
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.
7  0 
Avatar de GilbertLatranche
Membre averti https://www.developpez.com
Le 10/10/2017 à 14:40
En 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.
7  0 
Avatar de Bousk
Rédacteur/Modérateur https://www.developpez.com
Le 10/10/2017 à 16:40
Discord 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.. ça
8  1 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 09/10/2017 à 9:49
Citation Envoyé par nnovic Voir le message
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 Voir le message

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.
7  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 09/10/2017 à 13:42
Citation Envoyé par nnovic Voir le message
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).
7  1 
Avatar de kedare
Membre expérimenté https://www.developpez.com
Le 09/10/2017 à 16:06
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 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)
6  0