L’une des critiques qui revient souvent en JavaScript, c’est le nombre incalculable de paquets sur NPM qui ne sont plus maintenus. Et pourtant, la communauté JavaScript est très active dans les projets open source, preuve en est, une bonne partie des projets qui sont dans les “trendings” de GitHub sont souvent en JavaScript.
Mais alors pourquoi le nombre de projets abandonnés est aussi important, et doit-on s’en inquiéter ? Ces projets sont-ils réellement abandonnés, ou considérés comme terminés ?
Move Fast and Break Things : un écosystème volatile
Les années en JavaScript s’enchaînent et ne se ressemblent pas, chaque framework a son ère… On pourrait s’inquiéter d’assister à leur mort lorsque la hype redescend.
Et pourtant, jQuery est toujours maintenu aujourd’hui et même une version 3.2 a vu le jour récemment. La branche d’AngularJS 1.X est toujours activement supportée par la communauté, et les sites basés sur ces frameworks sont toujours sur pied.
La volatilité des frameworks demande un temps d’adaptation pour les développeurs. Certains frameworks comme React ont une API très simple à prendre en main, d’autres sont plus complexes (Angular par exemple). Il est donc difficile d’estimer le temps qu’un développeur mettra pour être confortable avec le nouvel écosystème d’un projet.
Les transitions de framework, que ce soit côté serveur ou côté client, ont toujours été liées à une problématique ou une complexité devenue trop importante. Leur diversité est une preuve de l’évolution de la manière de concevoir des applications Web (par exemple, le DOM virtuel, les composants Polymer ou encore les initiatives comme Dart).
Dans la diversité naît également la concurrence et par extension, l’amélioration du langage. Par exemple, la façon de penser une application monopage en JavaScript a aujourd’hui beaucoup changé. Le JSX et l’approche orientée composant propose une manière élégante de mixer la logique et son rendu, alors qu’on était auparavant restreint à l’utilisation de templates externalisés avec une gestion des événements bien plus complexe.
Une maturité dans l’immaturité
Je dois avouer que cet article est un peu une réponse à certains articles virulents envers JavaScript, et qui en dressent un portrait bien triste. On décrit le JavaScript comme possédant des bibliothèques non stables, non documentées, avec un tooling pauvre, et surtout comme une “obligation” d’en faire parce qu’il n’y a pas d’alternative.
Dans certains de nos projets, nous sommes amenés à utiliser des paquets NPM sans activité depuis plusieurs mois et une documentation sommaire. Mais cela ne veut pas dire qu’ils sont pour autant abandonnés, on peut juste les considérer comme des projets terminés. Comme ce sont souvent des micro paquets, on ne peut pas vraiment les comparer à ce qui se fait dans d’autres langages tels que Ruby, ou Python. Ces paquets proposent souvent une unique fonctionnalité avec une API très élégante à utiliser. Il y a plusieurs facteurs qui permettent de voir si une librairie est robuste : regarder sa couverture de test, si elle répond à l’intégralité d’une problématique, si elle est encore utilisée, et enfin si les tickets ouverts sont plus orientés fonctionnalité manquante que bug.
Il faut ajouter à ça le contexte d’exécution assez unique du Javascript. En effet, l’ECMA Script étant une spécification, les navigateurs ont la tâche d’implémenter leur propre moteur d’exécution JavaScript. Ce contexte fait que certains navigateurs n’ont pas accès à certaines fonctionnalités récentes comme `map` ou `reduce`. Mais cela ne veut pas dire qu’il ne faut pas les utiliser. On accède alors à ces nouveautés via des _polyfills_ en JavaScript ou des transpilers comme le projet Babel. Cela a permis à de nombreuses libraires comme [Lodash](https://lodash.com) ou [Underscore](http://underscorejs.org/) de briller par les nombreuses fonctionnalités qu’elles proposent, en délaissant la problématique du support.
Ce qui amène à une conclusion un peu trop hâtive qu’on retrouve souvent : la bibliothèque standard de JavaScript est très légère. Mais quand on y regarde de plus près, cette approche permet une évolution plus aisée du langage. Une partie des fonctionnalités est maintenant externalisé dans des bibliothèques, alors qu’il faut attendre jusque 2 à 3 ans pour adopter les nouvelles versions de Ruby, Java, Python ou autre. C’est un parti pris qui permet de rendre le langage plus souple et permet de proposer une compatibilité avec des anciennes implémentations.
Les divergences d’opinion, ou des implémentations différentes
La nature du libre fait que, si son auteur ne souhaite plus maintenir le paquet, soit le projet est repris, soit il est laissé à l’abandon. On va donc devoir nager dans une masse de plugins jQuery non maintenus, et coller à JavaScript une image de langage fait de _hacks_ à droite à gauche.
Mais, pourtant, cette approche un peu chaotique a permis également de développer bon nombre de concepts qui ont permis de faire avancer à la fois le langage et également le monde du Web tel qu’il est utilisé de nos jours.
Les divergences d’opinion amènent à la réflexion, la réflexion mène à une approche différente du problème et qui peut potentiellement faire naître une meilleure solution. Ce n’est pas inhérent à JavaScript, aujourd’hui ce raisonnement vaut pour l’ensemble des langages.
Si immature que ça ?
Pour répondre à la question posée en début de ce billet, non il ne faut pas s’inquiéter de la grande diversité des paquets et d’un abandon progressif de certains. Il faut plutôt regarder pourquoi il a été remplacé, dans quel but, et s’il répond parfaitement à vos besoins. Même si un paquet JavaScript peut paraitre éphémère, on peut noter la bonne volonté de la communauté de proposer des paquets testés décemment, de garder un _versionning_ sémantique, ou encore un suivi des issues. Il y a également un bon nombre de frameworks qui ouvre un salon sur des outils comme Slack pour échanger sur des problèmes ou sur des améliorations possibles.
JavaScript aujourd’hui peut être vu comme une couche bas niveau du web, comme l’a fait Js_Of_Ocaml, et peut être amélioré par des pré-processeurs comme JSX ou Babel. Il reste toujours l’image du front-end que certains développeurs ont de ce langage, et c’est dommage car, JavaScript peut proposer également des solutions élégantes à des problèmes qui sont parfois plus complexes dans des langages comme Ruby, PHP & Python.
Je pense fortement que JavaScript est un langage critiquable certes, mais comme tous les autres. Le sentiment immaturité vient surtout des développeurs qui veulent se conforter dans un choix d’une technologie et d’un langage qu’ils maîtrisent. Comment juger de l’utilité ou de la pertinence d’un langage sans en avoir compris les fondations ou même sa philosophie ?
