Discussion :

[Stéphane le calme]

Les bibliothèques JavaScript ne reçoivent presque jamais de mise à jour une fois qu'elles sont installées,
selon une enquête de Cloudfare

Fin 2019, Sacha Greif et Raphaël Benitte ont publié leur rapport annuel sur l’état de JavaScript et de son écosystème en entier. Environ 11 millions de développeurs utiliseraient JavaScript. L'étude State of JavaScript 2019 a interrogé plus de 21 000 développeurs JS sur leurs frameworks, outils et fonctionnalités préférés. Les résultats ont montré comment que l’écosystème JS a évolué et quels outils sont les plus utilisés en 2019.

Le rapport 2019 sur l'état de JS a révélé les principaux frameworks de travail du langage, les données démographiques sur les utilisateurs et d’autres données importantes. Qu'on l'aime ou qu'on le déteste, le langage continue de gagner du terrain et son écosystème ne cesse de grandir. Il est essentiel au développement moderne et est le premier langage de programmation sur GitHub depuis 2014, le langage Python ayant pris la deuxième place cette année devançant ainsi Java.

C'est ainsi que TypeScript a été classé premier en matière de satisfaction. TypeScript est un surensemble typé qui se compile en JS pur. 2018 et 2019 ont été des années majeures pour TypeScript et son adoption. Selon l’étude, si l'on remonte en 2016, la notoriété de TypeScript auprès des développeurs était déjà de 97 %, mais l'intérêt dépassait à peine la barre des 50 %. En 2019, tous les développeurs qui ont répondu à l'enquête savent ce qu'est TypeScript et un pourcentage impressionnant de 58,5 % l'utiliseraient à nouveau. De même, 89 % des répondants se sont déclarés satisfaits de TypeScript. Il s'est classé au premier rang en matière de satisfaction, d'intérêt et de notoriété par rapport aux autres langages qui compilent en JS (Elm, Rason, ClojureScript et PureScript).

En ce qui concerne les frameworks et les bibliothèques front-end, Angular et React sont deux des plus grands noms. L'année dernière, il a été constaté une baisse de la satisfaction à l'égard d'Angular. Cette année, il poursuit sa tendance à la baisse. Environ 35,8 % des développeurs ont déjà utilisé Angular, mais ne l'utiliseront plus. En comparaison, 21,9 % ont utilisé Angular et ont déclaré vouloir l’utiliser à nouveau. Cependant, ce pourcentage pourraient peut-être évoluer cette année lorsque la version stable d'Angular v9 sera publiée.

Mais les bibliothèques JavaScript ne sont presque jamais mises à jour une fois installées

C'est le constat d'une étude de Cloudfare qui a été rapportée par Zack Bloom :

« Cloudflare permet d'exécuter CDNJS, un moyen très populaire d'inclure JavaScript et d'autres ressources front-end sur les pages Web. Avec la permission de l'équipe CDNJS, nous collectons des données anonymisées et agrégées à partir des demandes CDNJS que nous utilisons pour comprendre comment les gens font leur développement sur Internet. Aujourd'hui, notre analyse se concentre sur une question : une fois installées sur un site, les bibliothèques JavaScript sont-elles mises à jour ?

« Prenons jQuery, la bibliothèque JavaScript la plus populaire sur Terre. Ce graphique montre le nombre de demandes effectuées pour une liste sélectionnée de versions de jQuery au cours des 12 derniers mois:

Les pics dans les données CDNJS comme vous le voyez avec la version 3.3.1 ne sont pas rares, car les très grands sites ajoutent et suppriment des balises de script CDNJS

« Nous constatons une augmentation constante de la version 3.4.1 après sa sortie le 2 mai 2019. Ce que nous ne voyons pas, c'est un déclin substantiel des anciennes versions. La version 3.2.1 montre une popularité moyenne de 36 millions de requêtes au début de notre échantillon, et 29 millions à la fin, soit une baisse d'environ 20 %. Cela correspond à un corpus de recherches qui montre que le site Web moyen dure entre deux et quatre ans. Ce que nous ne voyons pas, c'est une baisse de nos anciennes versions qui se rapprochent du volume de croissance des nouvelles versions lors de leur sortie. En fait, la version 3.4.1, aussi populaire qu'elle le devient rapidement, ne change pas du tout la tendance à la dépréciation de l'ancienne version.

« Si vous êtes curieux, la version la plus ancienne de jQuery CDNJS inclus est 1.10.0, sortie le 25 mai 2013. Le projet reçoit toujours en moyenne 100 000 requêtes par jour, et les sites qui l'utilisent gagnent en popularité*:

« Pour confirmer notre théorie, considérons un autre projet, TweenMax :

« Comme ce package n'est pas aussi populaire que jQuery, les données ont été lissées avec une moyenne de suivi d'une semaine pour faciliter l'identification des tendances.

« La version 1.20.4 commence l'année avec 18 millions de demandes et la termine avec 14 millions, soit une baisse d'environ 23 %, toujours en ligne avec la durée de vie de sites Web sur Internet. La croissance de 2.1.3 montre clairement que la sortie d'une nouvelle version n'a presque pas d'incidence sur la popularité des anciennes versions, la ligne de tendance pour ces anciennes versions ne change pas même si la 2.1.3 atteint 29 millions de demandes par jour ».

Source : Cloudfare

Et vous ?

Avez-vous fait appel à une bibliothèque JavaScript pour vos développements ? Laquelle / lesquelles et pourquoi ?
Avez-vous déjà effectué une mise à jour ? Si oui, à quelle fréquence ?
Qu'est-ce qui pourrait, selon vous, expliquer pourquoi plusieurs sites n'effectuent pas les mises à jour de leurs bibliothèques JavaScript ?
Est-ce selon vous propre aux bibliothèques JavaScript ou cela peut-il être observable sur d'autres bibliothèques ?

[grunk]

Est-ce selon vous propre aux bibliothèques JavaScript ou cela peut-il être observables sur d'autres bibliothèques ?

C'est pas propre à javascript. Combien de logiciel utilise par exemple une version d'openssl obsolète ?
Combien de client payent pour de la maintenance applicative (et donc ce genre de màj) ?

Le problème c'est que l'écosystème repose très lourdement sur les dépendances et que le moindre projets peux vite se retrouver avec 200 dépendances sans vraiment s'en rendre compte et c'est autant de faille potentielle quand ce n'est pas maintenu.

[darklinux]

C 'est un boulot qui devrais être fait par les admins et bien sur les mainteneurs

[Sodium]

Vu que chaque projet JavaScript a 200 dépendances ayant elle même 200 dépendances ce n'est pas étonnant, d'autant plus que le code est beaucoup plus difficile à tester que dans d'autres langages.

[micka132]

L'autre jour j'ai récupéré un projet web qui contenait du bootstrap 3.
J'ai voulu passer en 4. Je suis vite repassé en 3 .

[kilroyFR]

Tant que les devs se soucient de la retrocompatibilité ca marche sans efforts. Seulement de nos jours, faire du refactoring complet de code avec toutes les consequences ca ajoute un surcroit de taf que tout le monde n'est pas pret a realiser.
Donc c'est comprehensible, si le gain a migrer du code sur de l'existant est trop important personne ne prend le risque sur un gros projet en production.
On a tous subit ceci, angular et autres ou il faut tout reprendre le code parce qu'on a sauté de version. Comme generalement il n'y a pas de budget pour ceci, soit on prend sur soi a le faire (avec le risque de regressions et de se prendre un branlon par la hierarchie pour une initiative "inutile" soit on ne change rien tant que ca marche.

Maintenant on retrouve ceci pas seulement dans du javascript, on a meme soucis sur librairies open source C#. faut se resigner

[darklinux]

Vu que chaque projet JavaScript a 200 dépendances ayant elle même 200 dépendances ce n'est pas étonnant, d'autant plus que le code est beaucoup plus difficile à tester que dans d'autres langages.

C 'est bizarre , sous VSC , tu va dans le marketplace et " au miracle " , tu as des outils de test et de sécurité pour ça

[gretro]

J'aimerais pointer quelques petites failles dans l'argumentaire de cet article.

Le premier est que jQuery n'est plus vraiment d'actualité. Beaucoup de sites de cette époque l'utilise encore, et c'est probablement pour cela que l'on ne voit pas le déclin escompté. Je doute que ces projets soient encore en développement actif.

Le second argument rejoint un peu le premier. De nos jours, avec les bundlers tels que Webpack et Parcel, beaucoup de projets n'utilisent plus les services de CNDJS, mais bien leur propre CDN pour héberger un paquet de vendeurs. Avec ce contexte en tête, combien de projets a-t-on laissé en plan avec ces statistiques? Bien souvent, les projets activement maintenu sont également ceux qui vont mettre à jour leur dépendence. Je serais curieux que l'on répète l'expérience, mais avec les données de npm cette fois-ci.

[el_slapper]

C'est pas propre à javascript. Combien de logiciel utilise par exemple une version d'openssl obsolète ?
Combien de client payent pour de la maintenance applicative (et donc ce genre de màj) ?

Le problème c'est que l'écosystème repose très lourdement sur les dépendances et que le moindre projets peux vite se retrouver avec 200 dépendances sans vraiment s'en rendre compte et c'est autant de faille potentielle quand ce n'est pas maintenu.

le problème n'est pas nouveau, Joel Spolsky en parlait déjà il y a 20 ans : https://www.joelonsoftware.com/2001/...here-syndrome/

L'équipe EXCEL des années 90, semble-t-il, avait zéro dépendances - à un point qu'ils avaient même leur propre compilateur. C'est sans doute excessif dans la plupart des cas, mais les empilement de bibliothèques(qui existaient déjà à l'époque, mais qui sont vraiment partout maintenant) sont excessifs dans l'autre sens.

(oui, je vais sans doute prendre des pouces rouges. c'est pas grave).

[grunk]

Économiquement c'est difficilement viable de travailler sans aucune dépendances (sur des projets conséquents en tt cas).
D'ailleurs y'a surement plus de temps de travail sur les dépendances que sur la totalité d'un projet client qui n'est finalement "que" de l'assemblage de brique métier

[L33tige]

Économiquement c'est difficilement viable de travailler sans aucune dépendances (sur des projets conséquents en tt cas).
D'ailleurs y'a surement plus de temps de travail sur les dépendances que sur la totalité d'un projet client qui n'est finalement "que" de l'assemblage de brique métier

Pour être tombé sur des projets qui étaient en dépendances circulaires et qui ont du êtres migrés sous Maven je ne peux que plussoyer...

[Sodium]

C 'est bizarre , sous VSC , tu va dans le marketplace et " au miracle " , tu as des outils de test et de sécurité pour ça

Des outils de tests qui trouvent que dans telle dépendance de dépendance de dépendance il y a pas eu un très léger changement de comportement qui fait qu'un élément ne répond plus exactement de la même façon dans un cas très précis sur un browser précis évitant des heures de recherches juste pour parvenir à reproduire le bug ? J'achète tout de suite

[ManPaq]

Ce serait pas aux packages manager ou aux gestionnaires de dépendances d'assurer les mise à jour des bibliothèques? C'est le cas pour le framework Laravel de php avec composer...

[Marco46]

Vu que chaque projet JavaScript a 200 dépendances ayant elle même 200 dépendances ce n'est pas étonnant, d'autant plus que le code est beaucoup plus difficile à tester que dans d'autres langages.

Je vois pas le rapport entre le nombre très élevé de dépendances dans un projet JS moderne et la testabilité d'une appli. Les outils de tests en JS sont aussi bons que dans n'importe quel autre écosystème, encore faut-il les utiliser et écrire des tests pour son appli.

La vraie différence entre l'écosystème JS et les autres écosystèmes c'est que JS évolue beaucoup plus vite. En seulement un mois la totalité de vos dépendances nécessitent une mise à jour.

Sans tests automatisés c'est effectivement ingérable de maintenir car même en lisant rigoureusement les changelogs des différentes dépendances il faut bien tester.

Donc deux choses à faire pour éviter de laisser pourrir son app :

- avoir des suites de tests automatisées permettant de s'assurer du fonctionnement de l'application en un clic / script.
- effectuer les mises à jour très régulièrement (plusieurs fois par mois).

Un projet sérieux en 2020 est inséré dans une pipeline d'intégration continue permettant l'exécution des tests à chaque révision de la code base, est versionné par Git et utilise un service de type Greenkeeper / dependabot / etc ... qui ouvre pour le développeur des PR / MR contenant les montées de version dès qu'elles sont détectées par le bot.

Cette enquête révèle un symptôme pas le véritable mal qui est l'adoption encore faible de la culture DevOps.

[Sodium]

Comme d'hab, ce sont des discours bien beaux en théorie mais qui sont à côté de la réalité. Mise à part quelques rares exceptions, dans tous les domaines, personne n'a le temps de faire son job à la perfection. Les clients comme les patrons veulent les choses vite et pour un budget aussi serré que possible. Ils veulent également pouvoir changer d'avis et apporter des changements radicaux 15 fois au cours du projet et là, faire du code de trop bonne qualité devient limite un handicap.

[Marco46]

Comme d'hab, ce sont des discours bien beaux en théorie mais qui sont à côté de la réalité.

Ça fait pas loin de 7 ans que je n'ai plus vu aucune mission où on t'empêche d'écrire des tests, au contraire c'est de plus en plus souvent exigé. Mais il faut prendre le temps de choisir ses missions

Mise à part quelques rares exceptions, dans tous les domaines, personne n'a le temps de faire son job à la perfection.

Il ne s'agit pas de faire son job à la perfection mais de faire son job. Écrire du code d'un côté et les tests associés de l'autre sont les deux faces d'une même pièce.

Les clients comme les patrons veulent les choses vite et pour un budget aussi serré que possible. Ils veulent également pouvoir changer d'avis et apporter des changements radicaux 15 fois au cours du projet et là, faire du code de trop bonne qualité devient limite un handicap.

Je constate qu'écrire du code testable et testé permet d'être bien plus rapide et "agile" que de tester à la main. Parce que sans tests automatisés l'alternative c'est de tester à la main.

Ce que t'es entrain d'écrire ce n'est ni plus ni moins que c'est plus rapide d'effectuer une tache à la main que de l'automatiser, pour un informaticien c'est quand même un comble !

[rt15]

jQuery 2.1.3 ici (qui date de décembre 2014), sur un projet en développement actif...

Un problème est que l'on dépend de jQuery mais on dépend aussi de librairies (de notre boîte) qui dépendent de jQuery.
Un deuxième problème est que l'on a beaucoup de mal à libérer du temps pour la dette technique car on a déjà du mal à réaliser les évolutions et faire la maintenance en temps et en heure.

[walfrat]

J'ai une mise à jour Angular qui a dû attendre la mise à jour d'une librairie avant qu'on puisse upgrader.

De plus quand on commence à avoir pas mal de choses et surtout un logiciel qui a été validé, mettre à jour est souvent mal perçu car devra requérir une nouvelle recette complète. L'automatisation des tests est un sujet encore pas très important là où je suis.

[Marco46]

@walfrat il faut quitter ce genre d'organisation, elles sont toxiques pour ta carrière car entrain de pourrir sur elles-mêmes.

Qu'une organisation ait des soucis pour automatiser sa recette mais y travaille c'est une chose car c'est difficile à mettre en oeuvre, mais qu'une organisation considère ça comme un non-sujet c'est grave. C'est la preuve de dysfonctionnements et d'incompétence dans toute la chaine hiérarchique et en particulier aux plus hauts échelons. Incompréhension totale des enjeux et des conséquences de la part de la direction. Cela signifie que les personnels en charge de la stratégie IT ne sont pas formés à l'IT moderne, ils ont tout simplement 10 ans de retard. Si l'organisation est sur un secteur concurrentiel et que son activité dépend de l'IT, sa survie même est menacée à moyen terme.