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

on est dans la phase de l’adolescence. Ça cri, ça bouge, ça a plein d’énergie, et ça mérite des baffes.

— par Sam & Max

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 ?

[…] On peut faire plus de choses qu’avant. De manière plus propre […] 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é.

Livré sans commentaire, mais j’aimerais bien les vôtres.

Publié

21 janvier 2016

dans

javascript

par

Éric

Étiquettes :

Commentaires

9 réponses à “La communauté JS est actuellement une machine à créer de la dette technique”

Plop

21 janvier 2016

Beaucoup de troll dans cet article (comme souvent) mais surtout, le dernier paragraphe n’a au final absolument rien à voir avec le problème du javascript mais tout à voir avec une gestion de projet calamiteuse, quelque soit la techno (j’ai déjà vu exactement la même situation sur des projets java par exemple).

Après oui, c’est un peu le bordel, mais contrairement à l’article je dirais exactement comme au temps de jQuery où tout le monde rajoutait à la main des plugin à ne plus quoi savoir en faire, sans savoir d’où ils venaient, sans pouvoir gérer les updates, etc.
Au moins avec les gestionnaires de dépendances actuel c’est plus agréable.

Mais globalement le monde du front s’est (trop) complexifié au niveau setup, configuration.

Répondre
1. Éric
  
  21 janvier 2016
  
  Oui, clairement la majorité du problème est liée à la gestion de projet et la culture de développement, et pas au langage lui-même. En même temps même si on parlait de Basic, un langage correct permet toujours de tout faire. La question c’est la culture et les outils que la communauté se créé autour de ce langage. Il faut avouer qu’on a complexifié beaucoup de choses, parfois réinventé la roue, et qu’on est probablement encore dans la jeunesse fofolle au niveau communauté. Quand on voit ce qui est fait dans PHP, Ruby, Python, ou d’autres environnements, il y a des défauts qu’on a du mal à comprendre dans l’environnement JS (défaut de gestion, pas de langage).
2. Plop
  
  21 janvier 2016
  
  > Il faut avouer qu’on a complexifié beaucoup de choses, parfois réinventé la roue, et qu’on est probablement encore dans la jeunesse fofolle au niveau communauté.
  
  Oui, c’est exactement ça. Et tant que la communauté ne deviendra pas plus mature ça ne changera pas beaucoup.
  Maintenant il y a tout à fait matière à se débrouiller sans tout se brouhaha inutile.
  Genre ne pas utiliser gulp, ni grunt, ni webpack, ni… et juste faire les choses simplement.
  Ça fonctionnait il n’y a pas si longtemps, ça fonctionne toujours si on le veut.
  
  Voir par exemple ce tweet de Sam Stephenson de Basecamp, que je trouve fort à propos :
  
  > Some things we don’t use in Basecamp 3: Angular. React. Ember. Backbone. jQuery UI. ES6. Babel. Browserify. Webpack. Anything from NPM. Grunt
  > https://twitter.com/sstephenson/status/687677053219438592
  
  Je ne dis pas qu’il ne faut rien prendre, mais qu’il est tout à fait possible de développer du js aujourd’hui en ne prenant que ce qui est nécessaire (et c’est valable pour tout dev) et en laissant de côté la part d’excitation inutile et excessive qui existe.
  
  Après, je me demande toujours si un part de tout ce côté « réinventons la roue de nombreuses fois » n’est pas non plus lié à un positionnement du js assez complexe. Pendant longtemps c’était juste pour bidouiller. Et maintenant il y beaucoup de monde qui s’y intéresse avec des niveaux et des aspirations très différentes. Beaucoup de nouveaux/peu expérimentés, pour faire du front, du back, les deux, etc. Et chacun voit des directions très différentes sur ce qu’il faut faire, les outils, etc.
  J’aurais dit aussi un peu comme PHP il y a quelques années, bien que ça semble aujourd’hui aller dans une autre direction, plus mature.
  Il ne reste qu’à espérer que JS prennent un chemin du genre un jour.
Spoder Min

21 janvier 2016

Je suis dev depuis pas loin de 10 ans, dont beaucoup (beaucoup, beaucoup) de PHP. Depuis quelques temps je m’intéresse à l’écosystème JS car je souhaite développer une application navigateur. Et je sèche. J’aime les choses cadrées, bien faites, propres, sécurisées, élégantes. L’engouement ces dernières années de la communauté PHP pour les tests unitaires, les PSR, composer, les libs indépendantes de qualité me plais énormément. Je trouve qu’il y a une certaine cohérence sans pour autant enfermer le développeur: Composer sert aussi bien a installer Laravel, Symfony qu’une lib standalone comme Monolog. Mais vouloir faire du JS « moderne » en 2015 / 16 c’est juste une curée: tellement d’outils à tous les niveaux, de pratiques, d’écoles, de standarts, … Pour mettre ne place un « simple » livereload il faut 50 fichiers de config et 12 000 libs . Dépassé le stade de la TODO app de démo, aucune entente sur une archi modulable et évolutive. Même au sein d’une même solution, on trouve 200 skeletons d’applications. Se lancer sur Angular: « Angular n’est qu’une copie du monde PHP / Python / Ruby / Java avec son MCV ». Pas dans la philosophie JS. React alors: « React c’est juste un moteur de template ». Ok, Flux ? « Flux c’est un paradigme à implémenter soit même avec d’autres outils. C’est juste la preuve que Facebook ne sait pas faire un module de notification cohérent ». Redux is’nt it ? « Une implémentation pure de Flux sans les inconvenient. Oh wait, on a ajouté aussi la notion d’immutable mais qui n’est pas obligatoire et plein de notion que tu comprendras dans 10 ans mais seront dépassées dans 2. On a mis dedans React Router aussi, car tout le monde le veux. Mais c’est pas du MVC ok! On a pas de modèle nous, mais un store mec! Pas Pareil. C’est juste un gros modèle avec tout dedans ». Et finalement: « Do you have a few minutes to talk about our lord Amber.js » …. Au final, je suis plus rassuré par un truc comme Ionic, un peu en vase clos, mais qui propose un écosystème complet et cohérent. Et j’ai pas parlé d’ES6 et des libs de compatibilité. Et de Browserify et consort. Affreux. J’en suis même venu à chercher comment runner du code PHP avec JS pour faire mon application peinard :p Je suis peut-être passé à côté de quelque chose mais j’ai des gros doutes sur la direction que tout ça prends et la pérennité de l’ensemble. My 2 cents

Répondre
1. Éric
  
  21 janvier 2016
  
  Attention quand même, une partie de ce que je ressens avec ton commentaire c’est que tu as du mal à changer de façon de voir et qu’il est plus simple pour toi de bosser avec ton outil habituel. C’est normal, mais pas forcément à reprocher à JS.
2. Spoder Min
  
  21 janvier 2016
  
  C’est vraiment pas l’envie qui m’en manque, mais je trouve que ça manque de point d’entrée clair. Ou alors il faut que je laisse tomber l’idée dans trouver un, faire un choix et m’y tenir.
Kilo

21 janvier 2016

Il ne faut pas oublier que ces nouveaux outils sont faits pour construire des IHM Web complexes, de plus en plus proche de ce que l’on peut faire dans les applications natives.

Alors oui, ces outils sont infiniments plus difficiles à mettre en oeuvre que jQuery, mais ils nous permettent aussi de faire des applications beaucoup plus abouties.

En ce moment j’utilise Angular ou React, selon mes besoins. Angular pour les IHM avec pleins de formulaires et React pour le reste.
Je n’utilise pas de surcouche JS comme Coffescript, ou Typescript car cela me semble trop risqué sur le long terme, et cela rend le debug plus délicat.
Concernant React, je n’utilise pas Flux, Redux…, le fonctionnement de base me suffit largement.

En revanche j’utilise ES6 avec babel. Ca complexifie légerment le build, mais ce n’est pas de la dette technique, car un jour les navigateurs le feront nativement.

Pour le build j’utilise selon les cas : npm scripts (on trouve vite les limites), gulp (la notion de flux rend parfois des choses simples compliqués), webpack (le pire! mais indispensable pour le build incrémental avec React sur les gros projets).
Aucune de ces solutions n’est satisfaisantes… Il reste peut être une place à prendre pour un Nieme outil de build, qui mettrait tout le monde d’accord :)

Répondre
karl

22 janvier 2016

Tous les billets provocatifs que l’on peut remarquer récemment sont beaucoup plus à propos des frameworks JS que de JS lui-même. Pour vraiment comparer, il faudrait probablement aligner ce qui se passe avec RoR, Django, Flask, Symphony, et autres vis à vis des Angular, React, etc.

Aussi pour avoir une cohérence, il faudrait comparer ce qui est pur framework back-end, parce-que dans le domaine front-end python, ruby et PHP sont inexistants (par nature même des navigateurs).

Ceci dit, pour le peu que j’ai touché à node.js (alors que j’avais grand espoir que ce soit enfin pour moi le déclic pour vraiment me mettre au JS en le sortant du navigateur), j’ai la nausée. Si en plus de cela tu ajoutes la pile frameworks dans les navs, il est vraiment que cela donne un peu envie de vomir. Maintenant, il ne s’agit que de moi et quand je vois l’engoument pour les technologies et devs centrés sur JS, je me dis qu’il doit y avoir quelquechose de profondément attractif dans la structure du système même. J’imagine que la feedback loop très courte (voir directement chaque effet dans le navigateur^H chrome.) aide beaucoup à être enjoué pour cela. Try and Fail and Maybe success. Peut-être le même type de saut qu’il y a entre le C++ (langage compilé) et python/ruby (interprêté). Ce qui probablement s’accompagne également des dégats relatifs à « ça marche » plutôt que « c’est solide. »

Beaucoup plus de questions sur le pourquoi que de certitude sur les raisons.

Répondre
Nicolas Hoffmann (@Nico3333fr)

24 janvier 2016

Vu de l’extérieur, c’est assez rigolo. Cette effervescence est déroutante quand on n’est pas à fond là-dessus et qu’on y regarde de l’extérieur comme moi. L’impression que j’ai : une jungle complètement délirante et immature, difficile à maîtriser, bordélique à souhait MAIS pleine de vitalité. Comme dans la nature (enfin, j’espère) : only the strong will survive.

Et surtout, les plus fainéants (c’est-à-dire les meilleurs) arriveront à tirer le bon grain de l’ivraie, enfin j’espère.

Perso, je développe principalement au taf’ avec jQuery car besoin compatibilité IE8, je n’ai pas de besoins ultra-avancés en JS. C’est pas hype, mais c’est plutôt robuste.

Je reconnais que la venue d’ES6 est vraiment intéressante, dans le sens ou l’on parie sur un langage et pas un framework (qui lui peut facilement décéder), et Babel permet quand même d’avoir la compat’ avec des navigateurs pas au top du support d’ES6 (c’est-à-dire à peu près tous). Je commence à bricoler doucement en ES6.

Par contre côté outils, le gros défaut que j’y vois (j’utilise qq scripts pour automatiser des tâches rébarbatives) : quand tu essaies ça, si ça marche, c’est super. Quand tu as un bug, pour comprendre d’où ça vient dans tout ce bordel, c’est la misère. C’est pour cela que je ne m’en sers que pour automatiser des tâches (externes), mais j’y laisse loin des sites tant que je n’en ai pas un réel besoin.

Répondre