Le langage JavaScript (JS) est présent sur tous les sites Internet au travers de divers frameworks dont se servent les développeurs Web. 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 lourdeur des sites qui découle de l’utilisation abusive de frameworks. C’est une redite de la prise de position des têtes derrière la plateforme en ligne Easy Laptop Finder selon laquelle « L’utilisation incessante de frameworks JavaScript de pointe a contribué à rendre le Web moins accessible. »
Envoyé par Easy Laptop Finder
L'utilisation incessante JavaScript de pointe a contribué à rendre le web moins accessible, en affectant de manière disproportionnée les utilisateurs dont les appareils et les conditions de réseau sont incapables (1) de télécharger les énormes charges utiles associées à ces frameworks et (2) de gérer la mémoire requise pour exécuter le code du framework dans le navigateur. L'accent mis sur la création d'applications hautement interactives entraîne une coupure d'accès au Web de certains internautes.
Pire encore, les personnes qui ont tendance à posséder des appareils moins puissants et celles qui vivent dans des zones où la connexion à l'internet est plus lente sont souvent celles qui pourraient bénéficier le plus d'un accès bien soutenu au web (par exemple, pour accéder aux services gouvernementaux).
La poussée de l'interaction peut également avoir eu un impact sur l'accessibilité du web : bien que les nouvelles chaînes d'outils de développement puissent inclure un certain niveau d'accessibilité, j'ai constaté que ce niveau était largement dépassé par les développeurs qui affichent et cachent des éléments sur toute la page sans se soucier des personnes qui utilisent des lecteurs d'écran.
Je ne suis pas sûr que nous y parviendrons un jour, mais une approche plus raisonnable consiste à donner la priorité à l'accès à l'information et à l'accessibilité plutôt qu'aux interfaces tape-à-l'œil. La seule chose que le Web nous apporte avant tout, c'est la prolifération et l'accès facile à l'information. Ne gâchons pas cela pour de nouvelles interfaces tape-à-l'œil
Pire encore, les personnes qui ont tendance à posséder des appareils moins puissants et celles qui vivent dans des zones où la connexion à l'internet est plus lente sont souvent celles qui pourraient bénéficier le plus d'un accès bien soutenu au web (par exemple, pour accéder aux services gouvernementaux).
La poussée de l'interaction peut également avoir eu un impact sur l'accessibilité du web : bien que les nouvelles chaînes d'outils de développement puissent inclure un certain niveau d'accessibilité, j'ai constaté que ce niveau était largement dépassé par les développeurs qui affichent et cachent des éléments sur toute la page sans se soucier des personnes qui utilisent des lecteurs d'écran.
Je ne suis pas sûr que nous y parviendrons un jour, mais une approche plus raisonnable consiste à donner la priorité à l'accès à l'information et à l'accessibilité plutôt qu'aux interfaces tape-à-l'œil. La seule chose que le Web nous apporte avant tout, c'est la prolifération et l'accès facile à l'information. Ne gâchons pas cela pour de nouvelles interfaces tape-à-l'œil
L’abus dans la mise à contribution React.JS, Vue.JS et autres Angular.JS rend les pages Web plus lourdes que jamais, avec des tailles de l’ordre du mégaoctet, difficiles à charger pour les tiers avec des connexions à bas débit
Selon cheatmaster30, les frameworks JS ont rendu la page Web moyenne désormais plus grande que jamais, les pages de 2 à 3 Mo étant plus courantes que jamais.
« C'est un fléau sur Internet, et beaucoup de personnes blâment les frameworks dans leur ensemble. Après tout, beaucoup de ces sites sont construits avec des frameworks JavaScript même quand ce n'est pas vraiment nécessaire (comme avec beaucoup de sites de news). Et un bon nombre d'entre eux utilisent aussi Bootstrap pour le CSS », a-t-il dit. Toutefois, selon lui, il ne s’agit pas là du vrai problème. « Je pense plutôt que le problème est l'état d'esprit des développeurs et des concepteurs dans de nombreuses entreprises », a-t-il déclaré.
Les frameworks auraient rendu les développeurs et les ingénieurs moins soucieux de leurs utilisateurs ou de leurs clients que par le passé, plaçant leur satisfaction au-dessus des utilisateurs de leurs applications. « Je crois fermement que beaucoup de développeurs et d'ingénieurs logiciels placent leur satisfaction professionnelle au-dessus de leurs utilisateurs ou de leurs clients », a-t-il déclaré, ajoutant que c’est ce qui a conduit les développeurs vers toutes ces pratiques douteuses, ainsi qu'à un manque d'intérêt pour ce qui compte.
Cheatmaster30 souligne que Webpack et des dizaines de composants NPM sont utilisés pour faire gagner du temps et de l'effort aux développeurs, sans tenir compte des kilo-octets (ou même des méga-octets) de JavaScript qui s'ajoutent au produit fini. Des composants tiers sont apportés avec des quantités importantes de CSS et de JavaScript, simplement pour éviter d'avoir à construire ces composants à partir de zéro, la taille de la page étant damnée (fonctionnalités inutiles, chargement lent, etc.).
Cheatmaster30 ajoute que les développeurs choisissent d’utiliser un langage ou une technologie pour effectuer un travail simplement parce qu’elle est “cool”, et non parce qu’elle est la mieux adaptée pour faire le travail. « Regardez tous ces sites de nouvelles reconstruits comme des SPA avec des frameworks JS très résistants. Ils n'ont pas besoin d'être faits comme ça, et ils ne devraient probablement pas l'être », a-t-il déclaré. Par ailleurs, il ajoute que ces choix ne s’observent pas uniquement chez les développeurs.
« Alors, créateurs, arrêtez de vous focaliser sur votre CV ou votre convenance personnelle. Cessez de faire passer vos propres intérêts avant ceux de vos utilisateurs et de gaspiller des centaines de kilo-octets pour des choses dont personne ne se soucie. Vous n'êtes probablement pas Facebook ou Google, et vous ne devriez pas concevoir ou construire des choses comme si c'était le cas. Faites plutôt ce qui est nécessaire pour le travail et offrez une expérience que l'utilisateur aimera utiliser, avec aussi peu de ressources que nécessaire. Faites cela, et vos utilisateurs et clients vous en remercieront », a-t-il conclu.
Même les bibliothèques JavaScript contribuent à cette situation comme l’illustre l’expérience de Gov.UK avec JQuery
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 75e centile.
- 10 % de temps de blocage en moins pour les utilisateurs au 95e 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é.
Source : ELF
Et vous ?
Les griefs mis en avant à l’encontre des frameworks 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 à ces frameworks 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 des frameworks et des bibliothèques JavaScript 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 
