La communauté JS est actuellement une machine à créer de la dette technique

La communauté JS est actuellement une machine à créer de la dette technique

Vous savez, quand on ne brule pas un Troll, ses blessures se soignent rapidement, et il attaque à nouveau.

Et vous savez également comme j’aime troller JS.

De plus, il y a quelque temps, je vous affirmais que NodeJS n’était pas mature.

Est-ce que l’écosystème JS a muri depuis ?

Et bien maintenant je crois qu’on a passé l’enfance, et qu’on est dans la phase de l’adolescence. Ca crie, ça bouge, ça a plein d’énergie, et ça mérite des baffes.

Je sais, je sais, je vais encore avoir une horde de fans boys qui aiment le typage mou et les champs de moustaches venir me dire que je devrais arrêter d’écrire, de coder et m’enfoncer la version imprimée de Wikipédia

Mais dans l’histoire de JS, y a pas eu un moment qui ne méritait pas un bon article de ce genre. A croire que c’est volontaire.

En l’occurrence, j’ai eu envie d’écrire cet article à la suite de plusieurs évènements successifs:

  • Je me suis mis à React, et ai du remettre à jour, encore une fois, tout mon env de dev JS.
  • J’ai discuté avec des clients qui ont voulu mettre ça en place et qui ont fait marche arrière, car impossible de choisir une stack.
  • J’ai fait des formations AngularJS 1 pour des grosses boites qui vont faire tout avec malgré le fait que le 2 arrivent et casse tout.
  • Mozilla annonce la cloture de persona.org (et merde…) et publie son code NodeJS en open source. Et c’est une très vieille version (0.4.5) ce qui fait qu’on lit des comments du genre : it’s F/OSS, but I’d strongly suggest learning from Persona’s design rather than directly re-hosting the code
  • Je suis tombé sur un article déprimant sur l’état du front end qui m’a semblé sortir directement de ma tête.
  • J’utilise NoSript depuis quelque temps et je constate un nombre incroyable de pages qui devraient être statiques ou quasi-statiques et qui sont inutilisables avec le JS désactivés.
  • Les pages Web deviennent de plus en plus obèses.

Mais on ne peut pas blâmer uniquement le langage. La communauté JS a pris la modularité tellement à l’extrême qu’aucune solution standard ne s’est démarquée pour rien : outils de build, libs de tests, solutions de routing, toolings fonctionnels, et même packages managers…

Même à l’intérieur d’un écosystème, c’est les poupées russes. Par exemple React peut être accompagné d’un pattern que Facebook appelle Flux. C’est du MVC monodirectionnel. Les modèles sont immutables. Le contrôleur est à base d’évènements. Les vues sont gérées par des widgets React. Rien de fou, mais ça faisait pas assez innovant alors ils ont inventé un nouveau nom.

Bref, ils ont leur propre implémentation, mais même la référence n’a pas gagné la guerre. Non, en JS, ça a déclenché immédiatement un concours de celui qui pisse le plus loin et vous pouvez (devez ?) choisir entre : Flux, redux, alt, reflux, flummox, fluxible, fluxxor, marty.js, fynx, MacFly, DeLorean.js, fluxify, fluxury, exim, fluxtore, Redx, fluxx. Les noms ne sont pas une tentative d’humour de ma part.

Ce qui donne les comments du genre :

What a wonderful example of the paradox of choice!

No wonder that it’s easier to get started with Meteor + React, than with Flux + React.

Pour rappel, Meteor est le truc le plus expérimental qui existe en termes de stack techno à l’heure actuelle.

Évidemment tous ces projets ont une documentation succincte, une durée de vie aléatoire, et on peut déjà lire des trucs comme :

Flummox 4.0 will likely be the last major release. Use Redux instead.

Ton projet

Et ils ne sont pas compatibles entre eux. Et en fait ils ne font pas exactement la même chose :

how does redux “replace” flummox, exactly? Seems like they have two very different approaches

Je vous mets les comments car je sais que vous n’avez pas le temps d’aller lire, et encore moins d’étudier chacun de ses projets pour décider duquel utiliser, déjà qu’il faut apprendre React… A vous ne saviez pas ce qu’était React ? Mais vous êtes à la bourre dites donc !

Rassurez-vous, choisir ce genre de techno a seulement un impact sur tout le code front de votre projet. C’est tout.

Mais les outils s’améliorent, et JS est de plus en plus facile à coder. Pas vrai ? Pas vrai ?

Nope.

React fait ramer misérablement la console de debug de Firefox.

Les préprocesseurs ont tout envahi, et si vous choisissez 4 libs, l’un sera en ES6, l’autre en typescript et la troisième en Dart. Et il faut un setup de connard pour debug du code de préprocesseur confortablement : détecteur de changement, builder, injecteur de code, source mapper…

Les frameworks comme Angular ou React ont une gestion d’erreur bien à eux, qui affichent des messages chelous.

Pourquoi ça ne marche pas ? Ben…

L’installation est devenue un enfer. Entre les dépendances dépréciées, les libs incompatibles, les différents outils de build, et les options de config et les plugins, c’est une merde incommensurable. Plusieurs standards d’installeurs (et outils joints) se tirent la bourre : AMD, CommonJS et Harmony. Vous vous souvenez du temps ou on copiait juste jQuery dans le répertoire static ?

Attendez, avec Webassembly on pourra même plus faire “read source”.

Donc JS…

On peut faire plus de choses qu’avant. De manière plus propre (enfin propre, on parle de JS là…).

Mais l’écosystème, c’est le bordel général, l’anarchie totale, et ça continue d’avancer, en laissant tout le reste derrière.

Les projets JS s’accumulent, de freelances en SS2I qui se pointent, codent ou (surtout) recodent, et repartent en laissant un projet qu’il sera imbuvable à reprendre, déprécié avant même d’être terminé, non documenté, non testé.

Un projet jetable.

sam artois

A propos de l'auteur

Samuel Artois est un développeur Python passionné d'automatisation et de marketing. Depuis plusieurs années, il a développé une expertise solide dans ces domaines et a su mettre ses compétences en pratique sur de nombreux projets.

Laisser un commentaire