C'est pas Sexy ni trendy ? Je prends !
jQuery, c'est pas Sexy ni trendy. Sauf que c'est partout.
Doit-on en rajouter sur les nouveaux projets ? Oui, si l'on considère que je fais mon beurre en vendant mon temps à des clients, et qu'il est limité.
Aucun client n'a l'argent nécessaire pour que je refactorise tout son code en ECMAScript 2015, ni pour que je lui dise "eh, je vais me former sur Vue.JS pendant 3 mois, et ECMASCript 2015 pendant 1 mois, et puis aussi sur Docker pendant 2 mois : vous me payez ? Oh et puis comme la compétence vient de l'expérience (et donc des merdes), je vais me faire la main sur votre appli en PROD, ça vous dérange pas, non ??".
Évidemment, durant cette période je serai indisponible pour maintenir ses outils critiques. Il va surkiffer, c'est sûr. Il va adorer que je lui fasse supporter le poids de mes propres décisions en lui imposant de graves contraintes pénalisantes sur son activité ! :aie:
J'évolue progressivement sur certaines fonctions JS, bien sûr, je cherche à optimiser, je lis des articles avec des alternatives, des méthodes plus performantes, mais toujours en mixant les critères de faciliter la maintenabilité tout en évitant de passer 1000 ans à tout réapprendre à chaque seconde. Les récentes refontes du standard ECMAScript en font pratiquement un nouveau langage.
Les => et autres ... dans les définitions de fonctions font que j'ai l'impression de me taper du Powershell !
VBScript est ultra compréhensible à la place, et même si ça prend 5 lignes de plus qu'en Powershell, c'est lisible, et je peux taper dans les WMI sans problème. Pourquoi passer à Powershell ? Ben non. Pareil pour jQuery, sauf dans des projets ou la perf est ultra-critique, mais ces clients là ont un budget illimité et n'ont pas de problème à payer des dépassements de budgets x3 à des SSII de dimension mondiale sans scrupules, et pas toujours très compétentes... sauf peut-être en optimisation de dumping vers des dev basés en Asie ou à Macao.
Le temps de formation, c'est du temps. Du temps de vie, de ma vie. Il est limité ce temps. Je pourrais y passer les week-ends ? Ahaha, allez, je ne serai jamais assez bon pour apprendre tout ce qui évolue et toutes ces plateformes sexy et trendy qui naissent, meurent, plus vite que la lumière en seulement 1,5 jours par semaine.
Angular.JS ? c'est super.. ah non pardon.. c'est déjà nul, vaut mieux Vue.JS. Et d'ailleurs pkoi apprendre le Javascript sauce ECMAScript 2015.. Y'a Typescript, non ?
Python ? Ouais, c'est du solide... !! Ah non pardon, Ruby c'est mieux. Je vais plutôt m'améliorer en C#.. non en F#.. et puis en R.. euh.. non en Y, en Z, en Z', voire en ZETA3 ou en PETA(ouchnok) .... Allez, on défonce tout ce qui est on-premise et on fonce sur le Cloud... Ah non, pardon, les serveurs cloud s'éteignent et perdent des données de milliers de boites chaque jour. Bon ben on va sur Docker.. ah ben merde c'est pas sécurisé et galère à sécuriser. J'aurais du réfléchir un peu plus avant de perdre mon temps et mettre mes client en danger.
:ptdr:
Bon je devrais prendre le virage du Node.JS.. ah ben attends, les 56 frameworks et libs que j'utilise sont mis à jour tout le temps, ou pas maintenus, ou alors je les ai tweakés à donf, ou alors pire, il ont été remplacés par des packages NPM de ransomware qui ont les mêmes noms ... Bon, alors je vais arrêter l'ASP Classic et passer à .NET.. attends.. on en est à combien d'itérations du Framework .NET déjà ?... le MVC, c'est mort. Les WebForms ? Pareil... comment s'appelle leur nouvelle mouture déjà ? . NET 5. Ah. Ok. Je dois tout réapprendre je pense, non ? Allez, encore une certif Microsoft sur mon tmeps libre. Ah ben j'en ai plus : j'essaye de vivre un peu et passer 2h par jour avec mon gamin avant de mourir. :?
À ce rythme là, j'ai compris depuis des années que suivre les modes ou les MAJ incessantes de chaque techno ou OS c'est une erreur.
Il faut du temps d'assimilation et de maturation. Regarder sans se presser, puis prendre si ça semble solide. Je me documente, je suis abonné à des NL de dev, de comm, de UI/UX, mais je n'en sélectionne que ce qui me semble pertinent pour maintenant et demain, qui ne prend pas 1567 ans à apprendre (à 90 ans max je serai mort, sot seulement 50 maintenant). Prendre et me former sur ce qui permet à mes clients de compter sur moi comme un expert des technos que je maitrise.
Ça va en faire braire une paire ici, mais je suis un expert en maintenance et en optimisation des performances ASP Classic depuis plus de 15 ans, et j'en ai pas encore 40. Et mes (nombreux) clients (et pas des petits) préfèrent dépenser chez moi 5% du budget que leur couterait une refonte risquée en n'importe quoi d'autre, sans compter le temps que ça leur prendrait. Oh, et puis je ne suis en concurrence avec personne sur cette techno. Ça m'évite de baisser mon froc à facturer du Wordpress customisé en Vue.JS + PHP + Python + Docker pour 5€ de l'heure. Je ne suis pas prêt de m'inscrire sur Fiverr ou 5euros.com pour être en concurrence avec 75% des dev de la planète qui se tirent la bourre sur les mêmes technos !
Et ouais je sais faire du rapide, du sécurisé, et du responsive. Je sais même utiliser du JSON et de l'AJAX (ouahhhhh !). Même que j'intègre du WCAG dans mes sites développés en ASP Classic, et que PageSpeed me fout du vert malgré la présence de jQuery. Calmons-nous, hein : on parle de jQuery, pas de Macromedia Flash v2 !
Lorsque jQuery sera mort, je serai là pour sauver la vie de mes clients dont le front-end repose encore dessus. J'aime être un bon spécialiste, pas un mauvais généraliste :) 8-)
1 pièce(s) jointe(s)
jQuery 3.6.2 est disponible et apporte de nouveaux sélecteurs dans Chrome
jQuery 3.6.2 est disponible et apporte de nouveaux sélecteurs dans Chrome,
mais a-t-on encore besoin de cette bibliothèque JavaScript en 2022 ?
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:
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:
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 ?
:fleche: Que pensez-vous de jQuery 3.6.2 ?
:fleche: A-t-on encore besoin de jQuery actuellement selon vous ?
:fleche: Utilisez-vous jQuery ou un framework / bibliothèque JavaScript en 2022 ?
