Hello,

Alors Electron c’est un système pour builder des applications qui combine

• un chromium modifié qui sert à gérer l’interface
  


• du node.js pour compléter les APIs de chromium
  


• du code glue pour bridger tout ça, notamment en fournissant des APIs javascript additionnelles au process principal, qui vont permettre de toucher certaines fonctionnalités de l’OS (piloter les fenêtres, le systray, les notifications, tout ça)
  
  
  
  ça permet de faire des applis en utilisant des technos web, tout en étant en mesure de les builder et de les déployer vers à peu près tous les systèmes sur lesquels on peut faire tourner chromium et node.js… Soit beaucoup " />
  
  
  
  Ceci dit, les détracteurs avancent différents arguments plus ou moins recevables:
  
  
  
   - Il y a les gens qui n’aiment pas javascript et diront que ce n’est pas fait pour faire de l’applicatif et qu’il faut arrêter d’étendre les usages du langage. Je mets cet argument en premier pour l’évacuer parce que pour moi c’est de l’ordre de la querelle de paroisse et des gens qui veulent conserver leur pré carré, souvent avec une pointe de crainte en voyant les mêmes technologies devenir de plus en plus universelles (peur de voir se dévaluer certaines compétences spécialisées par exemple, ou d’un “nivelage par le bas” du milieu du développement chez ceux qui n’ont jamais considéré les développeurs web comme de “vrais développeurs”)
  
  
  
   - Il y a ceux qui n’aiment pas la façon de faire une UI en techno web. Les goûts et les couleurs…
  
   
  
   - Il y a l’argument de la performance: Même si JS tourne bien, on peut faire mieux avec un langage compilé, et parfois encore mieux en allant faire des optimisations obscures à la mano. Dans l’absolu, c’est vrai. Maintenant est-ce que toutes les applis sont CPU/GPU-intensive au point d’avoir besoin d’aller dans le low level? Comme toujours avec les sujets perfs, c’est très cas-par-cas, et le mieux est parfois l’ennemi du bien. D’autant plus que node.js permet d’écrire des modules en C++ au besoin.
  
  
  


• Un autre argument lié à la performance, c’est la complexité de paralléliser les calculs et de bien gérer le CPU avec un moteur JS qui est par nature mono-threadé. Pour le coup c’est vrai, quand on veut faire des choses non-triviales, ce n’est pas évident et il faut bien connaître le moteur. Il est toutefois possible de s’inspirer de VS Code, IDE open source et optimisé au poil, écrit avec Electron. (C’est d’ailleurs assez hallucinant quand on sait que c’est Microsoft qui gère ça, alors qu’à côté leurs autres app Electron faites par d’autres teams sont très loin d’avoir la même qualité niveau perfs)
  
  
  


• Les applis Electron sont lourdes, en RAM comme en taille d’exécutable. C’est vrai et c’est un argument recevable. Chaque appli Electron package sa propre version de Chromium light et sa propre version de node.js,ce qui fait que toutes les apps Electrons font plusieurs Mo même si on n’a soi-même écrit que quelque ko de code applicatif. Il y a des tentatives pour mitiger ça avec des systèmes pour partager un runtime Electron entre plusieurs apps, mais c’est difficile à gérer à la fois pour les devs (obligés de prendre en compte le fait que leur code pourrait potentiellement tourner sur des versions différentes de node/chromium) et pour les utilisateurs qui ne sont plus dans le simple clic-executable-to-install.
  
  
  


• La sécurité ne coule pas de source. L’UI est un vrai chromium, étendu pour que le js qui tourne dedans ait accès à des APIs desktop.  Ce qui veut dire qu’une fenêtre d’une app Electron peut de base naviguer vers une url (d’ailleurs c’est comme ça qu’on lui fait loader l’UI, on la lance en lui faisant charger un document html local) qui pourrait potentiellement être n’importe où sur le web. Si un attaquant arrive à exploiter une app chromium, il peut potentiellement lui faire loader du code js remote qui pourra faire bien plus de dégâts que s’il tournait dans un navigateur. Il y a évidemment des mitigations, mais c’est potentiellement plus facile de se tirer une balle dans le pied sans faire exprès qu’avec d’autres technos.

En fait, il faut remettre ça en contexte, à la base Electron c’est le core d’Atom, un IDE orienté technos web made in Github (avant le rachat par Microsoft).

Dans ce contexte là, (puis VS Code dans la lignée directe) ça faisait 100% sens, et ça n’avait rien à voir avec vouloir éviter des formations aux devs:

• ce sont des outils développés pour faire des app js, intégrer un noyau node, un navigateur avec un V8 et les outils de debugs directement, dont les versions sont à 100% maitrisés avec la distribution, c’était assez bien vu (avec un méchanisme de dogfooding où l’outil sert à se développer lui-même)
  
  
  


• ça tourne sur tous les OS principaux employés par les devs
  
  
  
  Il y avait donc un business case très fort pour ce type de solution.
  
   
  
  Après, est-ce que c’était pertinent d’extraire le framework et de le mettre à dispo de tout le monde, et est-ce que toutes les utilisations qui en sont faites par des entreprises sont bien appropriée ? Il est probable que parfois oui, parfois non, c’est du cas et par cas et il faudrait voir les tradeoffs faits par chacun. (comme je n’arrête pas de le répéter à mes collègues: nous ne sommes pas Google, c’est pas parce que c’est bon pour eux que c’est bon pour nos problématiques.)
  
   
  
  Le truc, c’est que ce type de solution, tout comme les PWA dans une autre mesure, ça répond à un vrai besoin, le fameux “write once, run anywhere” promis par Sun avec Java avant le rachat par Oracle. Il s’agit pour les boîtes d’essayer de trouver le moyen de garder la main sur le canal de distribution malgré la disparité des plateformes, tout en réduisant les coûts. (et oui, dans les coûts en question il y a la formation, la réputation et l’attractivité pour le recrutement, ne nous leurrons pas là-dessus) Et quand on tente de résoudre ça, on se rend vite compte que le seul moteur quasi ubiquitaire, c’est le combo V8+blink  (évidemment, sauf sur iOS, parce qu’il en faut toujours un qui mette un verrou…)
  
  On peut regretter que les innovations viennent des gros,  mais ça coûte cher la R&D, et eux ils ont des piles de cash à mettre dedans ^^”