Discussion :

[Patrick Ruiz]

« Nous devons arrêter d’utiliser JavaScript », lance Douglas Crockford, le créateur de JSON
Dont la sortie suggère que le langage est devenu une usine à gaz après une trentaine d’années d’existence

Le langage JavaScript (JS) est présent sur tous les sites Internet et permet de rendre l’expérience utilisateur la plus agréable possible sur divers pans. Cela vient néanmoins avec un coût étant donné que ce langage s’exécute côté client (sur le PC de l’internaute) : la lenteur des sites qui découle de l’utilisation abusive de bibliothèques comme JQuery. C’est l’une des raisons pour lesquelles le créateur de JSON peut sortir comme cela a été le cas récemment pour prendre position : « Nous devons arrêter d’utiliser JavaScript. »

« Il y a 20 ans, je militais pour le JavaScript. J'expliquais que JavaScript était un langage bien meilleur que tout le monde ne le pensait et que si nous l'utilisions correctement, nous pourrions faire des choses extraordinaires et changer le monde. Et c'est ce qui s'est passé. Désormais, mon évangile est que nous devrions arrêter d'utiliser JavaScript », lance le créateur de JSON dont la sortie suggère que le langage JavaScript est désormais une usine à gaz après une vingtaine d’années d’existence.

Douglas Crockford est un programmeur et entrepreneur américain, notamment connu pour sa forte implication dans le développement du langage JavaScript et pour la création du format JSON. Il est également le développeur de l'outil JSLint, permettant de détecter des erreurs de syntaxe JavaScript ainsi que ce qu'il considère comme de mauvaises pratiques.

Depuis sa création pour rendre les premiers sites web dynamiques, JavaScript n'a cessé de gagner en popularité au fil des ans. Ce langage est resté le plus demandé de janvier 2022 à juin 2023, d’après des données de la plateforme DevJobScanner. JavaScript est présent sur quasiment tous les sites web, mais c’est suite à la « mode du tout JavaScript » que des problèmes font surface sur des sites Web en production.

En effet, ce langage permet de rendre l’expérience utilisateur agréable sur plusieurs pans :

• Aucun rechargement de la page pour une fonctionnalité spécifique (charger un liste, etc.).
• Permet de faire des animations.
• Evite de recharger une page pour valider des formulaires.
• Etc.

C’est une liste non exhaustive des possibilités que le langage offre. Le souci vient de l’utilisation tous azimuts de la bibliothèque JQuery par des programmeurs qui optent pour la facilité même dans des cas de figure où il est possible de s’en passer. Conséquence : l’exécution côté client du site Web se fait au rythme du chargement des éléments de la bibliothèque JQuery et donc à pas lents.

Ces programmeurs optent en général pour JQuery pour gérer des Sliders, des animations en tous genres, des pop-ups, des menus déroulants au détriment de CSS qui permet d’atteindre les mêmes objectifs tout en augmentant les performances du site web, car il n’y a plus de chargement de script inutile. Et donc s’il n’est pas possible de se débarrasser du langage JavaScript comme le suggère le créateur de JSON, il est question de se servir au maximum d’alternatives sérieuses dans le cadre de projets de développement web.

L'expérience de Gov.UK avec la bibliothèque JQuery pour JavaScript donne plus de détails techniques sur les raisons des appels à plus d'attention dans l'utilisation de JavaScript

En mars 2022, Matt Hobbs, Responsable du développement front-end de Government Digital Service (qui offre des plateformes, des produits et des services qui aident le gouvernement à devenir intégré, fiable et réactif aux besoins des utilisateurs notamment GOV.UK), a annoncé que GOV.UK avait supprimé sa dépendance jQuery. C'est un gros problème en ce qui concerne l'expérience utilisateur, car GOV.UK fournit des services et des informations en ligne pour le Royaume-Uni à grande échelle. Tout le monde n'utilise pas son MacBook Pro 2022 sur une connexion haut débit à couper le souffle. GOV.UK doit être accessible à tous, et cela signifie qu'il doit rester léger.

Voici quelques-uns des plus grands succès de Matt Hobbs sur ce que GOV.UK a remarqué en supprimant jQuery :

• Moins de temps de traitement frontal dans l'ensemble.
• 11 % de temps de blocage en moins au 75^e centile.
• 10 % de temps de blocage en moins pour les utilisateurs au 95^e centile. Ce sont des utilisateurs qui rencontrent des conditions de réseau et d'appareils très défavorables, et chaque gain de performance compte particulièrement pour eux.

L’équipe Bootstrap avait mis en avant des arguments similaires pour justifier l’abandon de JQuery

L'équipe Bootstrap qui a annoncé l'abandon de jQuery dès la première version alpha de Bootstrap 5 pour retourner à du pur JavaScript. Selon Mark Otto, créateur du framework et auteur du billet de blog qui a annoncé cette version alpha 1, « jQuery a apporté un accès sans précédent à des comportements JavaScript complexes pour des millions (milliards ?) de personnes au cours des quinze dernières années », et « peut-être qu'il a changé à jamais le JavaScript lui-même », mais le temps était venu pour l’équipe d’abandonner jQuery en tant que dépendance. Selon le billet, ce changement est rendu possible grâce aux progrès réalisés dans les outils de développement front-end et la prise en charge des navigateurs.

Le principal argument avancé pour justifier la suppression de jQuery dans Bootstrap v5 est que maintenant que plus de 95 % des fonctionnalités de jQuery sont désormais natives dans les navigateurs (les 5 % restants étant sans doute des bizarreries excessivement rétrocompatibles qui méritent d'être ignorées), ajouter une dépendance serait soit « stupide », soit un gaspillage de bande passante.

Dans la communauté des développeurs, les avis divergent quant à ce changement. Ceux qui l'ont bien accueilli reconnaissent que jQuery est l’une des bibliothèques les plus importantes de l’histoire JavaScript et a permis de créer de véritables applications Web. Ils estiment cependant que depuis lors, les différences entre les navigateurs se sont considérablement réduites et nous avons appris à créer des applications maintenables et évolutives de manière plus déclarative, grâce à des frameworks comme React, Angular et autres. Du coup, jQuery ne serait plus d'une grande utilité.

JavaScript fait partie des langages les plus populaires dans les offres d’emploi publiées sur la plateforme https://emploi.developpez.com/. Le langage fait en sus partie des mieux payés en région parisienne et en province, en 2023.

Les données sur developpez.com font état de ce que, malgré son aspect incontournable dans la programmation Web, JavaScript est en baisse continue depuis 2020. Il était en deuxième place en 2015, mais maintenant se retrouve en quatrième place du classement des langages les plus populaires sur la plateforme. C’est une indication de ce que, si les besoins en JavaScript ne sont pas prêts de s'éteindre, en revanche, il semblerait que la mode du tout JavaScript (avec, entre autres, son utilisation dans le célèbre node.js) est en train de s’estomper pour le plus grand des performances des sites Web.

Source : Douglas Crockford

Et vous ?

Les griefs mis en avant à l’encontre du langage JavaScript pour ce qui est du développement des sites Web sont-ils cohérents avec la réalité dont vous êtes au fait ?
Quelles sont les alternatives à JavaScript sur lesquelles vous vous appuyez pour livrer à vos clients des sites Web dynamiques exempt des inconvénients qu’une mise à contribution de JavaScript entrainerait ?
Quels sont les langages et outils dont vous vous servez pour développer des sites Web dynamiques sans vous appuyer sur JavaScript et des bibliothèques comme JQuery ? Quels sont les avantages de votre approche en comparaison de celle qui s’appuie sur JavaScript et ses bibliothèques ?

Voir aussi :

Prise en main d’ES6.Aperçu des principales fonctionnalités

Quelles sont les nouvelles fonctionnalités qui pourraient débarquer dans JavaScript en 2019 ? Un tour d'horizon des candidats pour ES2019

La version 12 de Node.js est disponible et serait 30 % plus rapide au démarrage que les versions précédentes

Apprendre à programmer en Node.js avec MongoDB : découvrir le paradigme de MongoDB axé sur les documents dans Node.js, un tutoriel proposé par IBM

[RenarddeFeu]

Le vrai problème, c'est le recours aux webapps et au cloud pour tout et n'importe-quoi, là où un client lourd suffit amplement.

[JRM73]

29 ans d'existence, js est sorti en 1995.

[Zefling]

Mais le CSS commence à devenir lui-même un langage de programmation. Ça va finir comme ça aussi

https://www.commitstrip.com/fr/2019/...s-everywhere/?

[el_juky]

Douglas Crockford est vrai expert de JS mais je pense que la partie jQuery est déjà sur le déclin, et depuis un bon moment, au profit de d'autres façons de faire (TypeScript et autre).

Mon avis perso : le JS doit évoluer, pour devenir un langage mieux typé. Mais ne plus l'utiliser, ce serait dommage tant il a des particularités intéressantes.
Je dirait plutôt qu'il ne faut plus l'utiliser "tel que beaucoup de développeurs le font", c'est-à-dire sans vraiment le connaître (mais c'était déjà le cas il y a 15 ans, quand les dev utilisaient jQuery...), et en important des bibliothèques dans tous les sens.

[supertonic]

Perso j'en ai trop RAS la casquette de dev en WEB je veux en sortir par tout les moyens !

Un temps je défendais bec et ongle cette vision du "full web", et les décideurs ne s'y intéressaient pas trop.

Maintenant c'est l'inverse, du SPA à toutes les sauces, même là où ça rend les choses trop lourdes et complexes.
Le marché du dev est largement tiré par le "fullstack", corvéable dans "tous les domaines".

[Daïmanu]

Question bête, mais on pourrait pas envisager d'utiliser un autre langage de script pour le web (côté client), par exemple du Python ou autre ?

Il faudra certainement une variante optimisé en terme de performance, et capable de manipuler le DOM et de faire de l'événementiel, mais ça réglerait ces soucis lié au JS je crois.

C'est une question ouverte, je n'ai pas assez de recul pour y répondre.

[nhugodot]

@Daïmanu:
Dart était sensé remplacer JS, Google avait fait un moteur d'art mais est est sorti, V8 aussi, JS a réussi à se mettre à la page (code et vitesse) et d'art permettant de se transpiler en JS, on est resté dessus. Mais vous pouvez donc passer à divers langages plus modernes transpilables en JS tels que Dart ou Elm.
Vous pouvez aussi passer à WebAssembly (WASM) et coder en C/C+/C#, voire Rust, Python, etc.
Et aussi éviter le web HTML et CSS pour coder avec un framework multicibles tel que Flutter (Dart) et générer le code cible Web (wasm ou HTML au choix!)

[ddoussot]

Cet article est un ramassis d'inepties et d'approximations.... Il ne faut pas confondre JQuery et JavaScript. Il existe aujourd'hui de puissants frameworks comme Angular, et JavaScript peut être amélioré avec Typescript.

[JonathanSaenger]

Avec razor/blazor dans C# et stimulus/twig dans php, j'ai pu largement me passer de javascript pour le front

[marc.collin]

un livre assez intéressant sur les système hypermédia
https://hypermedia.systems/

quand tu vois tous la complexité qu'à amené les différents framework, librairie ultra utilisé de nos jours alors qu'il est possible d'avoir le même résultat avec d'ancienne techno avec un temps de développement autrement plus cours

[Metal3d]

Je vois des confusions sur l'article mais aussi dans les commentaires...
JavaScript ne peut pas être comparé à Twig, ça n'a pas le même but et le calcul est fait à deux endroits différents.
JavaScript n'est pas jQuery, l'article laisse entendre que jQuery est actuel alors qu'il est surtout là pour des app non mises à jour.. jQuery est vraiment désuet en 2024.
Par contre je suis entièrement d'accord avec certains. On a trip fait de web App qui s'installent en mode desktop. D'un côté ça a permis de faire tourner la même app partout (Linux, Windows, Mac...) sans modification mais de l'autre côté on a tous les inconvénients qui se retrouvent sur un browser. Le code est devenu infernal et on doit mélanger des dizaines de technologies pour faire tourner un logiciel.

Je préfèrerai qu'on se penche à nouveau sur des framework client lourd, il en existe des multiplateforme comme "fyne.io" que j'affectionne.

Mais JavaScript est un langage très intéressant dans le monde du web, à condition d'arrêter de vouloir tout faire au travers de libraries lourdingues (genre l'horrible React)

[SkyZoThreaD]

J'aime faire du js du fait que ce soit web surtout. La gui est déjà toute trouvée
Et puis le client léger, quoi qu'on en dise, tant qu'on est dans du pas trop gros sans besoin de beaucoup de réactivité, c'est un gros plus pour le déploiement et l'acceptation des utilisateurs.
Ce qui me gave vraiment en revanche, c'est le manque de typage et surtout l'asychrone quasi permanent !
J'aimerais bien un truc proche du c# qui a des types et se travaille bien en synchro, même si il gère aussi bien l'asynchrone.
Je conviens que mon faible niveau est un facteur de mon dégout, mais comparativement je n'ai j'amais été autant paumé devand du code que depuis le js et ses 70 acolades/parentheses...
Dans certains codes, les tabulations arrivent à mi-écran ! Comment veux-tu relire des trucs pareils

[marc.collin]

htmx + langage backend que tu veux et tu arrive au même résultat utilisateur qu'un spa...
https://htmx.org/

[oxedet]

Jquery et tous les framework front ne sont que des surcouches de js...

[Gomoz]

Stimulus et Htmx sont des librairies... JavaScript. Et (spoiler), la fin du JavaScript n'arrivera pas demain.

[melka one]

N' etant pas pros mais ayant fait pas mal de chose en javascript, ce que dit douglas je le comprend, pour avoir exploité a fond les capacité des navigateur c'est a dire javascript les api le css et le DOM avec pour devise pas de framework ni de bibliothèques je comprend pas le pourquoi des framework et bibliothèques et surtout pourquoi la complexification du js et aussi du css qui prend le même chemin. Cette complexification force plus la mémoire pour tous retenir et l'apprentissage plus long mettant plus de cote la logique.

A la base js c’était simple et lisible et c"en est devenu compliqué pour rien a part peut écrire moins et encore j'ai des doutes, j'ai l'impression que l'on confond un code qui vas a l’essentiel et qui en conséquence est court a une syntaxe qui permet d’écrire plus court mais qui ne garantira jamais qu' un code aille a l'essentiel

ces histoire de biblio frameworks c'est comme l'ia c'est de mode mais ça ne règle pas le coté aller a essentiel d'un code, c'est juste fait pour qu'une personne qui s'y connais normalement voir pas beaucoup en code puisse dire a un vieux de la vielle qu'il est has-been par ce qu'il utilise des boucles for plutôt que des foreach alors qu'il code des supers trucs

[Zefling]

Jquery et tous les framework front ne sont que des surcouches de js...

Je pense que presque personne utilise de langage sans framework aujourd'hui. C'est possible, beaucoup plus léger, mais réinventer la roue ça demande tellement de temps.

[Fagus]

Question bête, mais on pourrait pas envisager d'utiliser un autre langage de script pour le web (côté client), par exemple du Python ou autre ?

Il faudra certainement une variante optimisé en terme de performance, et capable de manipuler le DOM et de faire de l'événementiel, mais ça réglerait ces soucis lié au JS je crois.

C'est une question ouverte, je n'ai pas assez de recul pour y répondre.

Comme dit nhugodot, si le but c'est d'éviter js, ce sera moins expérimental en dart + flutter (gros kit GUI, multi-plateformes, compilation en wasm), mais si le but c'est d'écrire en python parce que python c'est cool, alors il y a Brython.
J'ai fini un projet avec, ça marche bien. C'est un transpileur en javascript dans la page. Un fois que la transpilation est terminée, le code tourne sur le même ordre de grandeur en vitesse que du js. L'interpréteur python bénéficie du tree shaking et n'alourdit pas significativement la page. L'inconvénient c'est le coût de la transpilation qui est d'autant plus long qu'on importe de modules python (insensible sur pc, mais compter 1-2 secondes sur un téléphone bas de gamme d'il y a > 5 ans). Le code python reste interprété et ça se débugue comme du python. Evidemment, on ne peut importer que du python pur, pas des modules compilés.
Pour donner une idée, pour les calculs j'ai importés les fonctions du js plutôt que le module math pour le temps de chargement.

Il y a aussi transcript qui transpile en js avant le chargement de la page (hors ligne). J'ai pas testé. Apparemment, c'est plus léger et rapide, mais c'est plus limité. Je ne sais pas à quel point c'est plaisant à débuguer.

[devs.heaven]

N' etant pas pros mais ayant fait pas mal de chose en javascript, ce que dit douglas je le comprend, pour avoir exploité a fond les capacité des navigateur c'est a dire javascript les api le css et le DOM avec pour devise pas de framework ni de bibliothèques je comprend pas le pourquoi des framework et bibliothèques et surtout pourquoi la complexification du js et aussi du css qui prend le même chemin. Cette complexification force plus la mémoire pour tous retenir et l'apprentissage plus long mettant plus de cote la logique.

A la base js c’était simple et lisible et c"en est devenu compliqué pour rien a part peut écrire moins et encore j'ai des doutes, j'ai l'impression que l'on confond un code qui vas a l’essentiel et qui en conséquence est court a une syntaxe qui permet d’écrire plus court mais qui ne garantira jamais qu' un code aille a l'essentiel

ces histoire de biblio frameworks c'est comme l'ia c'est de mode mais ça ne règle pas le coté aller a essentiel d'un code, c'est juste fait pour qu'une personne qui s'y connais normalement voir pas beaucoup en code puisse dire a un vieux de la vielle qu'il est has-been par ce qu'il utilise des boucles for plutôt que des foreach alors qu'il code des supers trucs

Les frameworks JavaScript modernes vont bien au-delà de la simple fourniture d'une architecture de base et de fonctions préconstruites. Aujourd'hui, ils agissent comme des précompilateurs capables de produire du code optimisé (WASM). Next.js, par exemple, intègre des fonctionnalités avancées telles que le rendu côté serveur (SSR), la pré-rendu statique (SSG), le rendu avec rehydration, le rendu incremental coté client, tout en permettant une optimisation fine du processus de build. Un framework tel que Nextjs, permet de reduire drastiquement la frontière entre créer un site statique, creéer une SPA tout en permettant de faire un code simple et lisible. Je n'ai cité que Nextjs, mais il y a Remix, NuxtJS, etc... Chacun apporte son lot d'innovation qui permet au dev de rester focus sur le metier et de rédiger du code simple et clair. Et pour moi dev en Nextjs est bien plus simple, rapide que de faire du flutter par exemple. A l'époque ou je faisais du JQuery ca me sortait par le nez, les oreillles, etc...

Au regard de ce que je viens d'expliquer, je me demande si ce fameux lance Douglas Crockford est toujours à la page.