Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Stéphane le calme

57PARTAGES

21  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de grunk
Modérateur https://www.developpez.com
Le 28/01/2020 à 17:43
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.
7  0 
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 29/01/2020 à 9:48
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.
7  2 
Avatar de kilroyFR
Membre éprouvé https://www.developpez.com
Le 29/01/2020 à 17:22
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
5  0 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 02/02/2020 à 8:59
Citation Envoyé par Sodium Voir le message
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.
5  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 30/01/2020 à 11:20
Citation Envoyé par grunk Voir le message
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).
4  0 
Avatar de gretro
Membre actif https://www.developpez.com
Le 30/01/2020 à 4:49
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.
3  0 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 11/02/2020 à 10:47
@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.
3  0 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 03/02/2020 à 19:57
Citation Envoyé par Sodium Voir le message
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

Citation Envoyé par Sodium Voir le message

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.

Citation Envoyé par Sodium Voir le message

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 !
2  0 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 29/01/2020 à 13:09
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 .
2  1 
Avatar de grunk
Modérateur https://www.developpez.com
Le 30/01/2020 à 13:26
É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
1  0