Le « tout–JavaScript » ne se fera pas.
Il y a quelque temps de cela, un ami dev m’a dit :
« Dans quelques années, il n’y aura plus que du JS. »
Alors oui, dans les dernières années, le JS s’est imposé comme le langage de référence. L’avènement de **Node.js** a décuplé les utilisations de JS côté serveur, et des frameworks Front tels que *Vue, React, Angular* ont permis de se tourner vers l’ère de la WebApp, à mi-chemin entre un client lourd (en termes de fonctionnalités), et un client léger (en termes de disponibilité).
Mais cet engouement pour le « tout-JS » n’a fait que mettre en lumière ses limites.
Performance
Combien d’applications Web chargent en moins d’une seconde aujourd’hui ? Combien peuvent se targuer d’être aussi rapide qu’un client lourd ?
Alors oui, un logiciel mal codé ou une webapp bien optimisée vont probablement limiter cet écart, mais le nombre d’applications Web avec un écran de chargement de plus de 4 secondes est déjà très important et ne va cesser de croître.
Poids
Le Web s’alourdit. C’est un fait. Les frameworks comme Vue, React et Angular ont plein d’avantages, mais le poids des « bundles » créés est l’un de leurs inconvénients majeurs. Il n’est pas rare de voir plusieurs Ko voire des Mo de JavaScript défiler dans l’onglet Réseau de nos navigateurs. On utilise parfois un marteau-piqueur, alors que nos besoins pourraient être satisfaits par un petit coup de marteau.
Parallélisme et programmation concurrente
Fait : JavaScript a été pensé pour être exécuté de façon monothreadée.
Fait : Le modèle de concurrence de JavaScript repose sur l’asynchronisme, et une file d’exécution.
Fait : Node.js peut réaliser des opérations de façon multithreadée, mais l’interprétation de JavaScript se fait de manière monothreadée.
Fait : Node.js donne la possibilité de créer des nouveaux processus, en déléguant une partie de la création à l’OS.
Fait : Node.js et les navigateurs ont maintenant la possibilité de créer des “Worker Threads” et des “Web Workers” respectivement, ajoutant la possibilité de multithreading.
**Fait** : Bien qu'aujourd'hui, beaucoup de nouveaux mécanismes aient été mis en place dans Node et dans les navigateurs pour palier à cela, **JavaScript n'est pas un langage pensé pour le parallélisme, ni pour faire de la programmation hautement concurrente**.
Opinion : Si mon but est de créer une application avec des besoins de haute concurrence, je me tourne vers des langages qui ont été pensés pour la programmation concurrente dès le départ.
Disponibilité
Ici, la WebApp gagne probablement face au client lourd. Elle est disponible partout, à un login près. Mais le client lourd gagne si l’on considère qu’il peut être utilisé hors-ligne. Toujours est-il que l’on fait de plus en plus d’appels à des APIs, on accède à des bases de données distantes, on veut de l’interconnexion quoi ! On voit donc que dans notre écosystème, le client lourd perd de sa valeur de « système hors-ligne ».
Ce problème n’est pas lié réellement à la WebApp ou au client lourd, mais bien à un changement dans notre façon d’architecturer nos nouveaux systèmes. On préfère l’utilisation de services externes, le mot micro-services résonne de plus en plus dans nos tympans, etc. Une des réalités du code d’aujourd’hui, c’est notre engouement pour la composition de services, et nos technologies doivent s’adapter en conséquence.
Electron, la solution ?
Electron est un « framework permettant de développer des applications multi-plateformes de bureau avec des technologies Web »1.
En termes simples, Electron permet « d’empaqueter » une application Web (donc écrite avec notre bon JavaScript) pour en résulter un exécutable natif Windows, macOS ou GNU/Linux. Pour parvenir à réaliser ce tour de force, Electron utilise un noyau Chromium. C’est comme si vous installiez une version très très épurée d’un autre navigateur, et qu’il ne permette d’accéder qu’à une seule WebApp.
Très bien, nous avons donc des clients lourds écrits aujourd’hui en JS ! Bravo, le tout-JS est là !
Malheureusement non, car les applis Electron souffrent des mêmes problèmes que les applications Web qui tournent sur navigateur.
Electron est un très bon outil, mais il ne permettra pas de remplacer complètement les clients lourds « classiques ».
Le reste de l’écosystème logiciel
JS ne remplacera rien hors du contexte des applications. Vos drivers écrits en C, vos scripts écrits en bash, vos réseaux de neurones écrits en Python, tout ira bien pour votre code.
Vous pouvez dormir tranquille, le **"tout–JS"** ne vous fera pas de mal. 😉
Je ne sais toujours pas comment terminer mes articles.
« Qui dort se repose. »