Discussion :

[Stéphane le calme]

Pourquoi Gov.UK, le site Web d'information du secteur public du Royaume-Uni, a cessé d'utiliser jQuery.
La bibliothèque JavaScript est-elle toujours aussi utile et incontournable qu'à ses débuts ?

A-t-on vraiment besoin de jQuery aujourd'hui ? C'est une question à laquelle GOV.UK et l'équipe de Bootsrap ont répondu par un « non » retentissant. Le chef de l'unité de transformation numérique du gouvernement britannique a récemment annoncé une modification du site des services gouvernementaux du pays gov.uk : ils ont « supprimé jQuery en tant que dépendance pour toutes les applications front-end, ce qui signifie que 32 Ko de code JavaScript minifié et compressé ont été supprimés » pour tout, de la sélection d'éléments à l'attachement d'écouteurs d'événements. En tant que développeur, quel est votre avis ?

Créé pour simplifier l'écriture de JavaScript et HTML, jQuery est arrivé au bon moment en 2006, avec la complexification croissante des interfaces Web. Cela lui a permis de séduire en masse les développeurs Web et d'avoir le statut d'élément fondamental dans les formations aux technologies du Web.

jQuery est une dépendance d'environ 30 Ko utilisée par près de 84 % des pages mobiles en 2021, et pour cause. jQuery était un outil instrumental à une époque où nous avions vraiment besoin d'un moyen de scripter l'interactivité de manière à lisser les différentes implémentations de choses comme la gestion des événements, la sélection d'éléments, l'animation d'éléments, etc.

Voici un exemple d'Ajax avec jQuery :

Code jQuery :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$(document).ready(function() {                    // Lorsque le document est chargé
    $(".load_page_on_click").click(function() {   // Lorsque l’on clique sur un élément d'attribut class "load_page_on_click"
        var email = $("input[name=email]").val(); // Variable contenant la valeur d'un élément input d'attribut name "email"
        $.ajax({                         // Exécution d’une requête Ajax avec la configuration donnée par l'objet suivant :
            async: "true",               // - requête asynchrone
            type: "GET",                 // - type HTTP GET
            url: "mapage.php",           // - URL de la page à charger
            data: "email=" + encodeURIComponent(email) + "&action=get_email", // - données à envoyer
            error: function(errorData) { // - fonction de rappel en cas d’erreur
                $("#error").html(errorData);
            },
            success: function(data) {    // - fonction de rappel pour le traitement des données reçues en cas de succès
                $("#container").html(data); $("#error").append("Contenu chargé");
            }
        }); // Fermeture de l'appel à la fonction $.ajax
    });     // Fermeture de la fonction de rappel du $(".load_page_on_click").click
});         // Fermeture de la fonction de rappel du $(document).ready

Le Web est meilleur grâce à jQuery, non seulement parce qu'il a une utilité incroyable, mais parce que son omniprésence a conduit à intégrer ce qu'il a fourni à la plateforme Web elle-même. De nos jours, nous pouvons faire à peu près tout ce que jQuery peut faire en Vanilla JavaScript (un nom auquel se référer lorsque les développeurs utilisent du JavaScript simple sans aucune bibliothèque supplémentaire comme jQuery) :

• Nous pouvons sélectionner des éléments en utilisant une syntaxe de sélecteur CSS avec querySelector et querySelectorAll.
• Nous pouvons ajouter, supprimer et basculer des classes sur des éléments avec l'API classList.
• Nous pouvons attacher des gestionnaires d'événements aux éléments DOM et à la fenêtre en utilisant addEventListener.
• Et tellement, tellement plus.

jQuery était il y a peu la bibliothèque JS la plus utilisée au monde et bon nombre de frameworks l'utilisaient pour fonctionner. Mais avec l'émergence de nouvelles technologies (bibliothèques et frameworks) et la modernisation des navigateurs, le caractère incontournable, voire la pertinence, de jQuery ne fait plus l'unanimité. Les problèmes qui autrefois nécessitaient jQuery sont maintenant en train d'être résolus par les navigateurs et le standard EcmaScript en évolution. Certains développeurs ont donc commencé à prendre de la distance vis-à-vis de la bibliothèque JavaScript.

C'est le cas par exemple de 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é.

La suppression du moteur de sélection de jQuery parce qu'il existe maintenant des sélecteurs natifs dans les navigateurs modernes tend à donner raison à ceux qui pensent que jQuery est de moins en moins pertinent. D'autres estiment malgré tout que la bibliothèque JS est loin d'être obsolète, car les techniques jQuery ne sont pas aussi ergonomiques à mettre en œuvre sans utiliser jQuery. Pour ces derniers, ça reste donc un outil très productif qui offre des solutions simples à de nombreux problèmes.

Le cas du site gouvernemental britannique

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.

Le fil Twitter de Matt n'est pas avare en informations diverses, notamment sur la mesure détaillée des performances avec et sans jQuery.

Source : Matt Hobbs

Et vous ?

Avez-vous développé récemment en JavaScript ? Avez-vous fait appel à un framework comme jQuery ou un autre ? Lequel ?
Qu'en pensez-vous ? jQuery est-il toujours assez populaire en 2022 selon vous ?
Pensez-vous que jQuery soit encore pertinent au vu de l'évolution de JavaScript et d'autres paramètres comme les navigateurs, les débits de connexion, etc. ? Si oui, pourquoi ? Si non, dans quelle mesure ?
La bibliothèque JavaScript est-elle toujours aussi utile et incontournable qu'à ses débuts ?

Voir aussi :

La première version alpha de Bootstrap 5 est disponible avec des formulaires mis à jour et les propriétés CSS personnalisées, mais sans le support d'Internet Explorer et jQuery
La version 5.0 de Bootstrap supprimera le support d'Internet Explorer 11, cela fait suite à l'annonce de supprimer jQuery pour du pur JavaScript

[smarties]

Il me semble que quand le navigateur est trop vieux, Google nous jette car au niveau des certificats HTTPS ça coince.

jQuery a fait son temps et les navigateurs et les géants ont imposés leur technologies depuis plusieurs années. Donc je pense qu'il est grand temps d'abandonner progressivement jQuery.
Il y a maintenant des frameworks et npm qui fournissent beaucoup de ressources Javascript.

[Jitou]

Il y a deux ans j'ai voulu bannir de mon projet jquery car JavaScript propose les mêmes facilitées cependant les habitudes de certains développeurs sont difficiles à changer et Jquery a été réintégré a mon grand désespoir... J'ai quand même gagné une bataille de l'utilisation de fetch a la place de Ajax de Jquery ! Maintenant avec Bootstrap 5 je crois que j'interdirai purement et simplement Jquery je ne vois aucune raison de ne pas le faire aujourd'hui.

[el_juky]

Le JS de base m'a toujours semblé plus simple et plus pérenne que jquery.
Ça fait bien longtemps que cette librairie aurait dû être abandonnée (comme le suggérait le site https://youmightnotneedjquery.com/, créé il y a plusieurs années).

Les dev Web subissent ce qui s'annonçaient comme une évidence : ils doivent refaire le JS de leur site, voire réapprendre un langage qui a continué à évoluer. Ils doivent oublier le fameux wrapper $, qui est une hérésie au niveau des performances et du fait qu'il réimplémente ce qui existe déjà dans le langage de base (comme html, équivalent à innerHTML dans l'exemple donné).

[smarties]

En plus maintenant il y a aussi web assembly qui peut servir a faire des choses plus lourdes côté client

[marc.collin]

j'utilise encore jquery, car en autre la fonction ajax, load exécute le code js de la page retourné... chose que fetch ne fait pas.....

[domi65]

j'utilise JQuery indirectement, puisque les bibliothèques dont je me sers sont basées sur JQuery. Sinon, ça ne sert plus à rien pour deux raisons:
- celle invoquée dans l'article, à savoir les apports de ES 5 et 6
- la compatibilité des navigateurs avec les standards. Sauf bien sûr pour les quelques IE encore en service. Les utilisateurs ont le droit de faire de la résistance, mais j'ai le droit d'y résister ! ;-)

[Stéphane le calme]

GOV.UK, le site Web d'information du secteur public du Royaume-Uni, a cessé d'utiliser jQuery.
Le chef de l'unité de transformation numérique du gouvernement britannique en présente l'impact sur les performances web

Le chef de l'unité de transformation numérique du gouvernement britannique a récemment annoncé une modification du site des services gouvernementaux du pays gov.uk : ils ont « supprimé jQuery en tant que dépendance pour toutes les applications front-end, ce qui signifie que 32 Ko de code JavaScript minifié et compressé ont été supprimés » pour tout, de la sélection d'éléments à l'attachement d'écouteurs d'événements. Il revient pour partager l'impact sur les performances de leurs site web.

Créé pour simplifier l'écriture de JavaScript et HTML, jQuery est arrivé au bon moment en 2006, avec la complexification croissante des interfaces Web. Cela lui a permis de séduire en masse les développeurs Web et d'avoir le statut d'élément fondamental dans les formations aux technologies du Web.

jQuery est une dépendance d'environ 30 Ko utilisée par près de 84 % des pages mobiles en 2021, et pour cause. jQuery était un outil instrumental à une époque où nous avions vraiment besoin d'un moyen de scripter l'interactivité de manière à lisser les différentes implémentations de choses comme la gestion des événements, la sélection d'éléments, l'animation d'éléments, etc.

Voici un exemple d'Ajax avec jQuery :

Code jQuery :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$(document).ready(function() {                    // Lorsque le document est chargé
    $(".load_page_on_click").click(function() {   // Lorsque l’on clique sur un élément d'attribut class "load_page_on_click"
        var email = $("input[name=email]").val(); // Variable contenant la valeur d'un élément input d'attribut name "email"
        $.ajax({                         // Exécution d’une requête Ajax avec la configuration donnée par l'objet suivant :
            async: "true",               // - requête asynchrone
            type: "GET",                 // - type HTTP GET
            url: "mapage.php",           // - URL de la page à charger
            data: "email=" + encodeURIComponent(email) + "&action=get_email", // - données à envoyer
            error: function(errorData) { // - fonction de rappel en cas d’erreur
                $("#error").html(errorData);
            },
            success: function(data) {    // - fonction de rappel pour le traitement des données reçues en cas de succès
                $("#container").html(data); $("#error").append("Contenu chargé");
            }
        }); // Fermeture de l'appel à la fonction $.ajax
    });     // Fermeture de la fonction de rappel du $(".load_page_on_click").click
});         // Fermeture de la fonction de rappel du $(document).ready

Le Web est meilleur grâce à jQuery, non seulement parce qu'il a une utilité incroyable, mais parce que son omniprésence a conduit à intégrer ce qu'il a fourni à la plateforme Web elle-même. De nos jours, nous pouvons faire à peu près tout ce que jQuery peut faire en Vanilla JavaScript (un nom auquel se référer lorsque les développeurs utilisent du JavaScript simple sans aucune bibliothèque supplémentaire comme jQuery) :

• Nous pouvons sélectionner des éléments en utilisant une syntaxe de sélecteur CSS avec querySelector et querySelectorAll.
• Nous pouvons ajouter, supprimer et basculer des classes sur des éléments avec l'API classList.
• Nous pouvons attacher des gestionnaires d'événements aux éléments DOM et à la fenêtre en utilisant addEventListener.
• Et tellement, tellement plus.

jQuery était il y a peu la bibliothèque JS la plus utilisée au monde et bon nombre de frameworks l'utilisaient pour fonctionner. Mais avec l'émergence de nouvelles technologies (bibliothèques et frameworks) et la modernisation des navigateurs, le caractère incontournable, voire la pertinence, de jQuery ne fait plus l'unanimité. Les problèmes qui autrefois nécessitaient jQuery sont maintenant en train d'être résolus par les navigateurs et le standard EcmaScript en évolution. Certains développeurs ont donc commencé à prendre de la distance vis-à-vis de la bibliothèque JavaScript.

C'est le cas par exemple de 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é.

La suppression du moteur de sélection de jQuery parce qu'il existe maintenant des sélecteurs natifs dans les navigateurs modernes tend à donner raison à ceux qui pensent que jQuery est de moins en moins pertinent. D'autres estiment malgré tout que la bibliothèque JS est loin d'être obsolète, car les techniques jQuery ne sont pas aussi ergonomiques à mettre en œuvre sans utiliser jQuery. Pour ces derniers, ça reste donc un outil très productif qui offre des solutions simples à de nombreux problèmes.

Le cas du site gouvernemental britannique

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.

Le fil Twitter de Matt n'est pas avare en informations diverses, notamment sur la mesure détaillée des performances avec et sans jQuery.

Impact sur les performances de gov.uk

Ce qui suit est un extrait du billet du chef de l'unité de transformation numérique du gouvernement britannique

Données d'image versus données compressées

Comme mentionné précédemment, la bibliothèque jQuery n'était que de 32 Ko de JavaScript compressé et minifié (lorsque les espaces blancs étaient supprimés du code et remplacés par des mots répétés). Maintenant, je sais ce que vous pensez peut-être, cela ne ressemble pas à beaucoup de données, surtout par rapport aux images qui peuvent avoir une taille de plusieurs mégaoctets. Mais quand c'est sur chaque page, du point de vue des performances Web, cela équivaut à beaucoup de données. Il convient également de mentionner qu'il existe une grande différence entre les données d'image et les données JavaScript compressées. Les navigateurs et les appareils traitent les 2 types de données très différemment.

JavaScript est connu comme une ressource "bloquant le rendu". Cela signifie que lorsqu'un navigateur rencontre JavaScript, il passe par un processus en plusieurs étapes qui implique qu'il soit téléchargé, puis décompressé, avant d'être finalement analysé et exécuté. Tout cela se produit dans l'unité centrale de traitement (CPU) et la mémoire disponibles d'un appareil. Ces tâches peuvent être très lentes et énergivores selon l'appareil et la connexion.

Malheureusement, pendant ce temps, le dessin réel des pixels sur l'écran de l'appareil doit être suspendu jusqu'à ce que l'exécution du JavaScript soit terminée. Une fois terminé, le navigateur peut continuer à peindre des pixels pour le reste de la page.

Les images et les données d'image ne "bloquent pas le rendu", ce qui signifie que des parties de la page Web peuvent être peintes sur la page pendant que des données d'image supplémentaires sont téléchargées en parallèle. Par conséquent, une image de 32 Ko a beaucoup moins d'impact sur les performances que 32 Ko de JavaScript compressé. Cela est particulièrement vrai pour les utilisateurs d'appareils à faible spécification qui sont généralement plus lents, plus anciens et moins chers.

Aider les utilisateurs avec des appareils à faible spécification

Les appareils aux spécifications inférieures sont souvent considérés comme des ordinateurs portables et des tablettes plus anciens, ou des appareils mobiles "économiques" (souvent des appareils Android avec un forfait de données limité).

Étant donné que ces utilisateurs ont les appareils les plus lents, ils auront le plus besoin d'aide pour s'assurer que leur visite sur GOV.UK est aussi rapide, efficace et aussi bon marché que possible. En octobre dernier, l'Ofcom estimait que 2 millions de foyers " rencontraient des problèmes d'accessibilité avec leur haut débit fixe et/ou leur smartphone ", notre travail ici a donc le potentiel de réduire leurs coûts Internet.

À ce stade, il convient de mentionner que les données anonymes de Real User Monitoring (RUM) que nous collectons à partir des appareils des utilisateurs montrent que GOV.UK est déjà un site Web très rapide. Pour la majorité des utilisateurs, le site se charge en moins de 1 seconde. Mais le graphique de distribution (vu ci-dessus) montre également que certains utilisateurs voient un temps de chargement de page allant jusqu'à 2,35 secondes. En examinant de plus près les données de performances RUM de ces utilisateurs, nous constatons*:

• 75*% des utilisateurs sont basés au Royaume-Uni
• 35% des utilisateurs sont sur un appareil Android
• il faut presque 2 secondes pour que les pixels de la première page s'affichent sur leurs écrans (c'est ce qu'on appelle la métrique de rendu de début)

D'après les statistiques ci-dessus, nous pouvons supposer qu'il est fort probable que bon nombre de ces utilisateurs d'Android utilisent des appareils à faible spécification où la vitesse du processeur et la capacité de mémoire sont limitées.

Avec cette hypothèse à l'esprit, quel impact sur les performances la suppression de 32*ko de code JavaScript compressé aura-t-elle*?

Tester l'impact

C'est là que nos tests de performance « en laboratoire » sont très utiles. Nous effectuons des tests tous les jours sur les pages GOV.UK en utilisant des appareils simulés et des vitesses de connexion spécifiques. Parce que nous pouvons répéter ces tests tous les jours, cela nous permet de surveiller ce que les changements que nous apportons au site font pour les vrais utilisateurs visitant GOV.UK.

Par exemple, pour un utilisateur simulé visitant la page d'accueil de Universal Credit sur un appareil à faible spécification et une connexion mobile 2G, nous pouvons clairement voir sur le graphique où le changement jQuery a été effectué.

La raison pour laquelle la page Universal Credit a été choisie est qu'il s'agit de la page la plus visitée sur GOV.UK selon nos données d'analyse. Il est donc important qu'elle se charge rapidement pour tous les utilisateurs, quel que soit l'appareil ou la connexion qu'ils utilisent. Comme le montre le graphique ci-dessus, le temps qu'il a fallu à la page pour dessiner complètement les pixels à l'écran (visuellement complet) est passé de 11,3 secondes à 9,4 secondes (une amélioration de 17 %).

En plus des améliorations visuelles complètes, des améliorations du temps de chargement des pages ont également été clairement observées. Le graphique ci-dessous montre que le temps jusqu'au chargement complet de la page est passé de 20,42 secondes à 18,75 secondes (une amélioration de 8 %) et le temps de chargement total de la page est passé de 19,44 secondes à 17,75 secondes (une amélioration de 9 %).

Enfin, nous constatons également une amélioration significative des mesures de performances interactives de la page, ce qui signifie qu'un utilisateur peut interagir avec la page beaucoup plus tôt. Les mesures d'interactivité sont importantes pour les utilisateurs car elles indiquent quand l'utilisateur peut interagir pour la première fois avec la page. La possibilité d'interagir avec une page donne aux utilisateurs l'assurance que la page fonctionne toujours.

Améliorer GOV.UK pour tous

L'amélioration des performances Web est souvent constituée de nombreux changements incrémentiels plus petits au fil du temps. C'est donc formidable de voir le soutien apporté à ce changement par la communauté des performances Web au sens large.

Comme vous pouvez le voir à partir de nos résultats de surveillance des performances ci-dessus, nous avons amélioré les performances des pages pour de nombreux utilisateurs qui ont des difficultés avec des appareils à faible spécification et des connexions lentes, même si GOV.UK est déjà un site Web très rapide pour la majorité des utilisateurs. Il peut sembler que 32 Ko de JavaScript ne sont rien sur le Web moderne d'aujourd'hui avec des appareils rapides et des connexions haut débit rapides. Mais pour une certaine cohorte d'utilisateurs, cela fait une grande différence dans la façon dont ils vivent GOV.UK.

Sources : Matt Hobbs, impact sur les performances

Et vous ?

Avez-vous développé récemment en JavaScript ? Avez-vous fait appel à un framework comme jQuery ou un autre ? Lequel ?
Qu'en pensez-vous ? jQuery est-il toujours assez populaire en 2022 selon vous ?
Pensez-vous que jQuery soit encore pertinent au vu de l'évolution de JavaScript et d'autres paramètres comme les navigateurs, les débits de connexion, etc. ? Si oui, pourquoi ? Si non, dans quelle mesure ?
La bibliothèque JavaScript est-elle toujours aussi utile et incontournable qu'à ses débuts ?
Quelle lecture faites-vous des résultats en terme de performance présentés par le chef de l'unité de transformation numérique du gouvernement britannique ?

Voir aussi :

La première version alpha de Bootstrap 5 est disponible avec des formulaires mis à jour et les propriétés CSS personnalisées, mais sans le support d'Internet Explorer et jQuery
La version 5.0 de Bootstrap supprimera le support d'Internet Explorer 11, cela fait suite à l'annonce de supprimer jQuery pour du pur JavaScript

[selmanjo]

Jquery pour ma part est utile et est non incontournable.

[marc.collin]

quel est le remplacement de

jquery.load?

en plus de charger le fichier, s'il y a du js, il le charge aussi....

[eomer212]

premiérement, supprimer jquery pour que du vanilla script qui serait en train de régler tous les problémes, est une erreur. est-ce que revenir au javascript basique est un progrés quand on voit les fonctions de jquery qui simplifient et sécurisent l'usage de fonctions javascript qui autrement seraient plus complexes et sources d'erreur..
deuxiémement, si c'est pour mettre du vanilla script et garder des structures de pages qui n'évoluent pas, sont toujours monolithiques en rechargeant systématiquement tout dés qu'on clique sur quoi que ce soit, c'est vouloir utiliser de l'electronique de haute volée avec une mentalité de l'age de pierre..
d'autant plus que comme toute autre resource, jquery est accessible à partir du cache dés la deuxieme ouverture.
et c'est pas comme si on était encore sous ie6 avec un 8086 ..
enfin, jquery est modulaire. vous chargez et utilisez ce dont vous avez besoin.
et il y a aussi la sureté d'execution. jquery est sûr dans son fonctionnement. pas besoin d'apprendre une technologie qui pour moi est plus un phenomene de mode. une de plus.
j'ai vu tellement de sites soit disant faits avec les dernieres technologies mais pensés par des noobs, trop imbus de leur jeunisme pour simplement essayer de comprendre ce que veulent les gens qui les utilisent. ou simplement remettre en cause l'une des seules technologies ou maniére de faire qu'ils connaissent.
enfin, l'argument type 'je me raccroche aux branches' de dire que ca ferait economiser de la bande passante aux utilisateurs. pathétique. à l'heure de la 5G, et de la fibre, sans parler de la mise en cache, c'est vraiment pathetique.

bref, du vent. s'ils sont contents de leurs efforts pour se debarasser d'une technologie qui marche.. tant mieux pour eux. tant d'energie qu'ils auraient pu concentrer sur la qualité de leur travail à destination des utilisateurs.
j'en ai vu passer des technos depuis le premier pc, en faire le compte est inutile, mais jquery est resté car il présente des solutions et une pérennité la ou tout le reste n'est que valse permanente.
c'est aussi une qualité pour des équipes qui ont autre chose à faire que de réapprendre en permanence de nouvelles maniéres de faire, ce qui est toujours un investissement en temps et un risque constant.
et on va pas parler des soit disant methodes agiles et autres qui ont fait gonfler les temps de développement et épuisent les équipes sur des dogmes foireux.
le meilleur investissement c'est de comprendre d'abord ce qu'on doit faire, avec quoi et pourquoi, plutot que de pondre comme un ejaculateur précoce des lignes de codes inutiles sur quelque chose qu'on a toujours pas compris.
ha, en me relisant et en relisant le machin de gov.uk, ils auraient certainement meilleur benefice à supprimer tous ces machins de surveillance des utilisateurs, et surtout à repenser le contenu..
car se satisfaire de pages qui se chargent en 18 secondes, c'est encore plus que pathétique.. on frole le crime de torture.. autrement appellé foutage de gueule par chez moi..

[eomer212]

j'utilise JQuery indirectement, puisque les bibliothèques dont je me sers sont basées sur JQuery. Sinon, ça ne sert plus à rien pour deux raisons:
- celle invoquée dans l'article, à savoir les apports de ES 5 et 6
- la compatibilité des navigateurs avec les standards. Sauf bien sûr pour les quelques IE encore en service. Les utilisateurs ont le droit de faire de la résistance, mais j'ai le droit d'y résister ! ;-)

ca, ca s'appelle juste de la segregation... ou autrement dit , de la feneantise.
les utilisateurs sont justement la plupart du temps victimes de ce type de pensée réduite,
"t'as pas le dernier machin, la derniere machine,, t'es naze, t'es baisé.. " tout le monde n'a pas les moyens d'acheter un pc neuf tous les 3 ans..
sans parler des utilisateurs industriels ou commerciaux qui doivent se contenter d'un pc sorti d'on ne sait quelle strate du temps passé et/ou qui devra faire l'affaire tant qu'il sera capable de demarrer sans exploser.

[Rolllmops]

ca, ca s'appelle juste de la segregation... ou autrement dit , de la feneantise.
les utilisateurs sont justement la plupart du temps victimes de ce type de pensée réduite,
"t'as pas le dernier machin, la derniere machine,, t'es naze, t'es baisé.. " tout le monde n'a pas les moyens d'acheter un pc neuf tous les 3 ans..
sans parler des utilisateurs industriels ou commerciaux qui doivent se contenter d'un pc sorti d'on ne sait quelle strate du temps passé et/ou qui devra faire l'affaire tant qu'il sera capable de demarrer sans exploser.

Internet explorer 11 date de 2013, il a été remplacé depuis longtemps par Edge et pour ceux qui ont un Windows incompatible avec Edge les alternatives gratuites ne manquent pas. On ne peut pas éternellement assurer le support de logiciels plus qu'obsolètes qui ne respectent pas les standards en vigueur. Il y a quelques années, on pouvait encore arguer qu'il y a des utilisateurs qui se voient imposés un browser par leur entreprise mais ça ne tient plus, l'essentiel du parc installé a été mis à jour depuis.

Utiliser encore Internet Explorer en 2022 est dans la très grande majorité des cas un choix personnel et ce n'est pas aux développeurs de se rajouter un travail conséquent pour supporter ce choix. Les stats sont claires, ces utilisateurs ne représentent plus qu'une poignée de pourcents des internautes et investir du temps pour satisfaire leur caprice ne peut plus se justifier stratégiquement.

[eomer212]

Internet explorer 11 date de 2013, il a été remplacé depuis longtemps par Edge et pour ceux qui ont un Windows incompatible avec Edge les alternatives gratuites ne manquent pas.

mort de rire. ou t'as vu que je faisais la promotion de ie?. il m'a bien assez fait chier. faut croire que comme beaucoup t'as lu en travers et sauté/pas compris des parties.. typique.

sort de ta bulle de certitudes.. va voir le vrai monde, l'industrie, la ou les gens travaillent, vraiment. et ou certains subissent le choix d'autres qui ne voient pas de rasions d'investir pour changer du materiel qui fonctionne encore ( ou plutot creve sur place en attendant de cramer vraiment un jour prochain)..
car paradoxalement, c'est la ou ils ont besoin que ca fonctionne, vraiment, et que ca rende de vrais services et que ca leur fasse gagner du temps. car eux paient et sont donc exigeants car ils en ont le droit.. eux sont consommateurs, et si t'as pas compris ce qu'ils font, comment et pourquoi, et comment les aider, malgré les choix délirants /douteux de certains decisionnaires, t'es out. direct.

est-ce qu'on serait dans le cas du noob dressé sur sa taupiniére et croyant embrasser et dominer le monde alors que son univers se limite aux quelques metres qu'il peut contempler.??

[smarties]

Aujourd'hui utiliser IE ça ne doit pas être facile au quotidien pour la navigation sur les sites web avec toujours plus de JS (dont les 3/4 voire plus des sites ne supportent plus IE).
En plus de l'arrêt d'IE annoncé, ça fait des dizaines d'années que l'on sait qu'IE n'est presque plus utilisé.

J'entends l'argument de ne pas vouloir changer de matériel tant que ça fonctionne (ça permet de faire des économies, c'est écologique). Mais ces gens là ont généralement des machines très vielles (avec des disques vieux, des connectiques en voie de disparition comme les ports VGA, série, parallèle) et le matériel est rarement dépoussiéré/nettoyé donc la panne risque fortement d'arriver.

Quand on ne gère pas un minimum le risque où que l'on écoute pas son service informatique de temps en temps ou que l'on ne modernise pas des petites choses de temps en temps, il arrive un jour ou ça nous explose à la figure et là : plus rien ne marche, stress à faire le pompier, stress avec l'arrêt de la production donc chute du CA, ...

Maintenant même avec des SoC on board type Raspberry on a suffisamment de puissance pour un petit poste bureautique et/ou avoir de la connectique industrielle.

[Rolllmops]

mort de rire. ou t'as vu que je faisais la promotion de ie?. il m'a bien assez fait chier. faut croire que comme beaucoup t'as lu en travers et sauté/pas compris des parties.. typique.

Il faudra préciser de quoi tu parles alors car IE est à peu près le seul navigateur grand public qui peut poser des problèmes aujourd'hui. Et si tu ne veux pas être lu de travers, commence par t'exprimer dans un français correct et moins agressif. J'ai effectivement tendance à survoler les messages lorsqu'il y a une faute tous les deux mots.

[grunk]

premiérement, supprimer jquery pour que du vanilla script qui serait en train de régler tous les problémes, est une erreur. est-ce que revenir au javascript basique est un progrés quand on voit les fonctions de jquery qui simplifient et sécurisent l'usage de fonctions javascript qui autrement seraient plus complexes et sources d'erreur..

Le problème est bien , là pour la majorité des utilisateurs , jquery n'est devenu qu'une simple simplification du JS , la plus part des utilisateurs ne connaissent d'ailleurs souvent pas les fonctions natives correspondantes. C'est quand même bien dommage d'embarquer et maintenir une librairie pour n'être qu'un wrapper de fonctions existantes. Autant écrire soit même les 3/4 fonctions dont ont à besoin.

deuxiémement, si c'est pour mettre du vanilla script et garder des structures de pages qui n'évoluent pas, sont toujours monolithiques en rechargeant systématiquement tout dés qu'on clique sur quoi que ce soit, c'est vouloir utiliser de l'electronique de haute volée avec une mentalité de l'age de pierre..

Quel rapport ? Pas besoin de jquery pour structurer un site ou le rendre dynamique

et il y a aussi la sureté d'execution. jquery est sûr dans son fonctionnement. pas besoin d'apprendre une technologie qui pour moi est plus un phenomene de mode. une de plus.

C'est vrai que ca serait dommage de connaitre la techno sur laquelle repose jquery. Perso je fais plus confiance au langage de base qu'à une librairie , aussi réputée soit elle (surtout quand la dernière release a plus d'un an).

bref, du vent. s'ils sont contents de leurs efforts pour se debarasser d'une technologie qui marche.. tant mieux pour eux. tant d'energie qu'ils auraient pu concentrer sur la qualité de leur travail à destination des utilisateurs.
j'en ai vu passer des technos depuis le premier pc, en faire le compte est inutile, mais jquery est resté car il présente des solutions et une pérennité la ou tout le reste n'est que valse permanente.

Faire du web et travailler avec des technos d'il y'a 10 ans , sous pretexte qu'elles fonctionnent est une erreur. La techno à tellement évoluée ces dernières années que faire un site aujourdhui avec jquery est signe d'une méconnaissance flagrante du domaine.
Sur des sites existants , son remplacement est effectivement discutable, mais surement un mal nécessaire dans le temps si on ne veux pas avoir à faire un refactoring complet à terme.

c'est aussi une qualité pour des équipes qui ont autre chose à faire que de réapprendre en permanence de nouvelles maniéres de faire, ce qui est toujours un investissement en temps et un risque constant.

Une équipe qui n'apprend pas , c'est une équipe qui est vouée à la mort. Alors oui il ne faut pas se jeter les yeux fermer sur toutes les nouvelles tendances , mais il faut savoir saisir celle qui ont de l'intérêt et qui sont là pour durer. En 2022 ne pas faire, au choix du react/Angular/ember/vuejs/alpinejs c'est perdre son temps.

et on va pas parler des soit disant methodes agiles et autres qui ont fait gonfler les temps de développement et épuisent les équipes sur des dogmes foireux.

Le pb des méthodes agiles c'est leur mise en oeuvre. Si tu as eu de mauvaise expérience, c'est qu'elle n'ont pas été appliquées correctement.

ha, en me relisant et en relisant le machin de gov.uk, ils auraient certainement meilleur benefice à supprimer tous ces machins de surveillance des utilisateurs, et surtout à repenser le contenu..

Ha ba la je suis d'accord

t'as pas le dernier machin, la derniere machine,, t'es naze, t'es baisé.. " tout le monde n'a pas les moyens d'acheter un pc neuf tous les 3 ans..

Tu remarqueras que JQuery sauf sur IE le support officiel , c'est dernière version -1. Autant dire qu'il faut un système relativement à jour ...

Comme tout le monde j'utilise et j'ai utilisé JQuery, elle su être là quand les acteurs du web ne savait pas se mettre d'accord. Aujourd'hui rien ne justifie son utilisation sur un nouveau projet.

[joKED]

Je peux, d'expérience, vous assurer que certains outils internes d'un grand FAI français tournent toujours avec du IE6 et Flash. Une vraie plaie.

[Doksuri]

au risque de me repeter (sur plusieurs threads deja) je conseille a tout le monde qui souhaite faire le changement d'abandonner jQuery de mettre ce lien en favoris
github.com/camsong/You-Dont-Need-jQuery/blob/master/README-fr.md il suffit de rechercher dans la page le nom de la fonction qu'on souhaite "ne plus utiliser" pour avoir l'equivalent en natif ...

de plus, avec jquery, on a tendance (moi a l'epoque) d'abuser de .animate ou de .slideUp/Down (et autres effets)...
=> c'est infiniment mieux de gerer les animations dans le css et d'appliquer une classe a l'element

[vanquish]

Ce qui est certain c'est que le site gov.uk (qui existe contrairement à gouv.fr) est extrêmement rapide et léger : aucune image, aucun partage vers les réseaux sociaux.

Le fait que le site racine gov.uk existe évite d'avoir à passer par google pour trouver le sous-site qui nous intéresse (impôt, justice etc.) est un plus indiscutable.
Pour le reste, je ne sais pas quoi en penser. C'est à la fois clair et hyper-réactif mais on dirait la page perso d'un site des années 90.
C'est presque à se demander à quoi leur sert javascript.

Pour comparer, j'ai regardé ce qui passait sur le réseau pour le site https://www.ecologie.gouv.fr/
Ils n'utilisent pas jQuery, mais s'ils l'utilisaient ce ne serait pas le 32 Ko de ce dernier qui serait le problème (quoiqu'on pense de ce dernier).