jQuery est une bibliothèque JavaScript libre et multiplateforme créée pour faciliter l'écriture de scripts côté client dans le code HTML des pages web. L'équipe responsable de son développement a annoncé la disponibilité de jQuery 3.6.2. Selon elle, l'impulsion principale de cette version a été l'introduction de nouveaux sélecteurs dans Chrome.Vous l'avez certainement deviné, la version jQuery 4.0 annoncée depuis quelques années déjà va devoir encore attendre. Cette version sera une refonte de la bibliothèque JavaScript. En effet, l'API de base de jQuery consiste à sélectionner un élément, puis à faire quelque chose avec ce qui a été sélectionné. Sizzle, le moteur de sélection dans jQuery, gère la première partie. C’est un petit moteur rapide et efficace qui a ouvert la voie à des API de sélecteur natif telles que querySelectorAll ainsi qu’à des sélecteurs JavaScript et CSS natifs supplémentaires. Mais maintenant, beaucoup de ces sélecteurs sont intégrés dans les navigateurs modernes. L'équipe jQuery estime donc qu'il est presque temps de dire au revoir à Sizzle, ce qu'elle prévoit de faire dans la version 4.0. L'équipe jQuery assure y travailler, mais d'ici là, elle continuera à prendre en charge la branche 3.x et à résoudre des problèmes importants.
Quelles sont les nouveautés / améliorations apportées par jQuery 3.6.2
variables CSS indéfinies et avec des espaces uniquement
jQuery 3.6.1 a introduit une régression mineure où la tentative de récupération d'une valeur pour une propriété CSS personnalisée qui n'existait pas (c'est-à-dire $elem.css("--custom")) renvoyait une erreur au lieu de renvoyer undefined. Cela a été corrigé en 3.6.2. Dans la même lancée, l'équipe s'est également assuré que les valeurs d'espace uniquement renvoient la même chose sur tous les navigateurs. La spécification exige que les valeurs des variables CSS soient coupées, mais les navigateurs sont incohérents dans leur coupe. jQuery renvoie maintenant undefined pour les valeurs d'espaces uniquement afin de le rendre cohérent avec l'ancien jQuery et sur les différents navigateurs.
| Code JavaScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 | @@ -28,17 +28,37 @@ function curCSS( elem, name, computed ) { // .css('filter') (IE 9 only, trac-12537) // .css('--customProperty) (gh-3144) if ( computed ) { // Support: IE <=9 - 11+ // IE only supports `"float"` in `getPropertyValue`; in computed styles // it's only available as `"cssFloat"`. We no longer modify properties // sent to `.css()` apart from camelCasing, so we need to check both. // Normally, this would create difference in behavior: if // `getPropertyValue` returns an empty string, the value returned // by `.css()` would be `undefined`. This is usually the case for // disconnected elements. However, in IE even disconnected elements // with no styles return `"none"` for `getPropertyValue( "float" )` ret = computed.getPropertyValue( name ) || computed[ name ]; // trim whitespace for custom property (issue gh-4926) if ( isCustomProp && ret !== undefined ) { if ( isCustomProp && ret ) { // rtrim treats U+000D CARRIAGE RETURN and U+000C FORM FEED // Support: Firefox 105+, Chrome <=105+ // Spec requires trimming whitespace for custom properties (gh-4926). // Firefox only trims leading whitespace. Chrome just collapses // both leading & trailing whitespace to a single space. // // Fall back to `undefined` if empty string returned. // This collapses a missing definition with property defined // and set to an empty string but there's no standard API // allowing us to differentiate them without a performance penalty // and returning `undefined` aligns with older jQuery. // // rtrimCSS treats U+000D CARRIAGE RETURN and U+000C FORM FEED // as whitespace while CSS does not, but this is not a problem // because CSS preprocessing replaces them with U+000A LINE FEED // (which *is* CSS whitespace) // https://www.w3.org/TR/css-syntax-3/#input-preprocessing ret = ret.replace( rtrimCSS, "$1" ); ret = ret.replace( rtrimCSS, "$1" ) || undefined; } if ( ret === "" && !isAttached( elem ) ) { |
.contains() avec <template>
Un problème a été récemment signalé qui montrait qu'un document <template> avait sa propriété documentElement définie sur null, conformément à la spécification. S'il était sémantiquement logique qu'un modèle ne soit pas encore lié à un document, cela constituait un cas inhabituel, en particulier dans jQuery.contains() et toutes les méthodes qui en dépendent. Cela comprenait des méthodes de manipulation et de sélection. Heureusement, la correction était simple.
Ce n'est pas Ralph qui a brisé Internet (clin d’œil au film d'animation Ralph 2.0)
Internet a connu une petite grogne lorsque Chrome a récemment introduit de nouveaux sélecteurs, dont le plus pertinent est :has(). C'était un ajout bienvenu, et célébré par l'équipe jQuery, mais une modification de la spécification signifiait que :has() utilisait ce qu'on appelle « l'analyse indulgente ». Essentiellement, même si les arguments de :has() n'étaient pas valides, le navigateur ne renvoyait aucun résultat au lieu de générer une erreur. Cela posait problème dans les cas où :has() contenait une autre extension de sélecteur jQuery (par exemple :has(:contains("Item"))) ou se contenait elle-même (:has(div:has(a))). La bibliothèque de sélection CSS Sizzle [ndlr. écrite en JavaScript, elle permet de parcourir le DOM d’un document (HTML, XHTML, XML etc.) à l’aide d’expressions CSS] s'est appuyé sur des erreurs comme celle-ci pour savoir quand faire confiance à querySelectorAll natif et quand exécuter le sélecteur via Sizzle. Les sélecteurs qui fonctionnaient plantaient dans toutes les versions de jQuery remontant aux premières versions de jQuery.
Et pourtant, ce petit drame n'a pas duré longtemps. L'équipe Chrome a rapidement mis en place une solution de contournement pour corriger les versions précédentes de jQuery dans la grande majorité des cas. Safari a géré leur implémentation de :has() un peu différemment et n'a pas eu le même problème. Le CSSWG a depuis résolu le problème.
jQuery a pris des mesures pour s'assurer que toute analyse indulgente ne casse pas les futures versions de jQuery, même si les versions précédentes de jQuery seraient toujours affectées.
A-t-on vraiment besoin de jQuery aujourd'hui ?
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 était il y a peu la bibliothèque JS la plus utilisée au monde et bon nombre de frameworks l'utilisaient pour fonctionner. 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 javascript : | Sélectionner tout |
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 |
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.
C'est aussi le cas de Gov.UK, le site Web d'information du secteur public du Royaume-Uni, a cessé d'utiliser 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.
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.
Source : jQuery
Et vous ?
Que pensez-vous de jQuery 3.6.2 ? A-t-on encore besoin de jQuery actuellement selon vous ? Utilisez-vous jQuery ou un framework / bibliothèque JavaScript en 2022 ? 
Envoyé par Stéphane le calme
