jQuery v4.0 bêta

• La prise en charge de IE 10 et versions antérieures est supprimée, et celle de Edge Legacy, iOS <11, Firefox <65 et Android Browser est également abandonnée
• Des API en état de prise en charge obsolète (deprecation) depuis plusieurs versions ont été supprimées : jQuery.cssNumber, jQuery.cssProps, jQuery.isArray, jQuery.parseJSON, jQuery.nodeName, jQuery.isFunction, jQuery.isWindow, jQuery.camelCase, jQuery.type, jQuery.now, jQuery.isNumeric, jQuery.trim, jQuery.fx.interval
• Les méthodes Array internes du prototype jQuery, push, sort, splice, ont été supprimées, ce qui peut affecter les plugins qui s'appuyaient sur elles
• Dans l'ordre des événements liés à focusout, blur, focusin, focus, l'ancien override de jQuery a été supprimé, et les navigateurs hors IE suivent désormais l'ordre W3C actuel : blur → focusout → focus → focusin
• jQuery.ajax prend en charge les données binaires et FormData, et le comportement qui consistait auparavant à traiter ces données comme un type inconnu puis à les convertir en chaîne est remplacé par un traitement automatique
• Le comportement de jQuery.ajax qui promouvait automatiquement en requête JSONP lorsqu'un dataType: "json" et un callback étaient fournis ensemble a été supprimé
• Le code source de jQuery a migré d'AMD vers les ES modules, et l'outil de packaging est passé de RequireJS à Rollup
• La prise en charge de Trusted Types a été ajoutée, ce qui permet d'utiliser du HTML encapsulé dans TrustedHTML comme entrée des méthodes de manipulation jQuery sans enfreindre la directive CSP require-trusted-types-for
• La plupart des requêtes de scripts asynchrones utilisent désormais la balise <script> afin d'éviter les erreurs CSP causées par l'utilisation de scripts inline
• Dans le build slim, Deferreds et Callbacks ont été supprimés, ce qui le fait passer sous les 20 kio en gzip, soit environ 8 kio compressés de moins que le build standard
• Si la prise en charge d'IE11 est nécessaire, il est recommandé d'utiliser le build principal plutôt que le build slim, ou d'ajouter un polyfill de Promises natives
• Un guide complet de mise à niveau sera publié avant la sortie officielle, et le plugin jQuery Migrate sera préparé pour aider à la migration
• La bêta est disponible sur le CDN jQuery et sur npm ; les CDN tiers n'hébergeront pas la bêta et hébergeront plus tard la version finale 4.0.0

[GN⁺]

Avis sur Hacker News

• Si vous vous demandez ce qui fait encore tourner jQuery après 2024, il faut garder à l’esprit que WordPress représente toujours plus d’un tiers du Web, et que la plupart des installations ainsi qu’innombrables plugins dépendent fortement de jQuery.
  C’est une bonne chose que la suppression des API ou fonctions dépréciées progresse, et jQuery restera probablement dominant sur le Web pendant encore plusieurs années.

  • En plus, jQuery est excellent.
    Ces quelque 15 dernières années, le secteur s’est un peu trop entiché de frameworks JavaScript complexes et tape-à-l’œil, alors que lier dynamiquement des formulaires générés à la volée, gérer les états d’erreur et faire quelques appels Ajax, c’est à peu près tout le JavaScript nécessaire pour 99 % des pages Web ; le reste est souvent excessif.
    Je pense que le secteur va s’éloigner de la complexité de React pour revenir vers la simplicité de htmx, Phoenix LiveView, Ruby on Rails Turbo, ou tout simplement jQuery.
  • Quoi qu’on en dise, jQuery reste puissant, important et très influent.
    Si l’on retirait jQuery de tous les logiciels, une bonne partie des sites Web sur Internet s’arrêterait de fonctionner.
  • Ce n’est pas qu’un problème WordPress.
    Une entreprise où je travaillais auparavant exploitait un produit SaaS d’entreprise avec des dizaines de milliers de lignes de code jQuery.
    Tant que ce ne sera pas strictement nécessaire, il ne sera pas réécrit avec un framework JS moderne. La plupart du code a été écrit il y a plus de dix ans pour répondre à des besoins clients précis, et l’argument selon lequel un framework moderne aiderait au recrutement ne tient pas non plus. L’entreprise ne paie ses ingénieurs front-end que 75 000 à 90 000 dollars, le turnover est faible, et la plupart des ingénieurs actuels sont là depuis plus de cinq ans.
    Surtout, la stack actuelle fonctionne bien et les anciens clients sont satisfaits. Une grande partie de l’ingénierie logicielle se fait dans ce genre de business ennuyeux, dans des villes où le coût de la vie est bien inférieur à celui des grands hubs big tech comme la Bay Area ou Seattle.
  • Les développeurs WordPress sont un peu les plombiers du secteur tech.
    Ce n’est pas glamour, mais il y a tellement de gens qui en ont besoin qu’on peut très bien gagner sa vie.
    Si un jour je prends ma retraite du monde des startups big tech qui court après les dernières tendances, j’aimerais gagner honnêtement ma vie en créant des sites WordPress et terminer mes journées tous les jours à 15 h.
  • J’ai failli poster ça sur HN il y a quelque temps, mais je n’ai toujours pas trouvé de bon modèle de chaînage/bubbling d’événements qui permette aux membres du DOM et aux instances de classes abstraites de déclencher des événements de manière interchangeable.
    J’ai écrit des dispatchers d’événements maison un peu partout, mais jQuery fait vraiment bien cette partie. Aujourd’hui encore, j’utilise jQuery presque uniquement pour la gestion d’événements, mais c’est tellement utile que je l’inclus dans presque tous mes projets côté client.
    Ce que je voulais demander, c’était si quelqu’un connaissait une bibliothèque légère capable de gérer avec la même API $(window).trigger('click') et $(myClassInstance).trigger('myCustomEvent',{data}), y compris l’écoute asynchrone.
    Avec la montée en puissance de fetch() et des sélecteurs CSS, je peux désormais me passer du reste de jQuery, mais est-ce vraiment la peine de réinventer la roue ? Avant de dire que faire dispatcher des événements par une instance de classe est une mauvaise odeur de code, c’est indispensable si l’on veut construire un framework réactif à partir de zéro.
    Par exemple, ma classe de composant de base écoute certains événements personnalisés de resize émis par l’écran qui la contient, et cet écran n’envoie l’événement qu’aux composants qui doivent réorganiser leur contenu interne sans que l’écran lui-même ne défile. La classe écran écoute window.resize, mais ne redispatch que lorsque la mise en page devient problématique. Attacher un listener DOM resize distinct à window pour chaque composant n’a aucun sens.

• Je suis surpris de voir régulièrement sur HN des gens considérer jQuery comme une simple bibliothèque de sélection DOM.
  En réalité, c’est une boîte à outils largement prise en charge et très stable, qui fournit non seulement la sélection DOM, mais aussi la manipulation d’attributs, les requêtes Ajax, la gestion d’événements, les animations et des fonctions utilitaires générales.
  Et même lorsqu’il existe des fonctionnalités natives qui remplacent jQuery, leurs API ne sont pas aussi élégantes.
  Pour des tâches où il suffit d’ajouter un peu de fonctionnalité à du HTML rendu côté serveur, sans avoir besoin d’un framework complet d’interface JS, jQuery représente un faible coût en tant que dépendance stable, fiable et compatible entre navigateurs.

  • J’ai abandonné jQuery il y a quelques années pour passer au JavaScript pur, et je n’ai jamais regardé en arrière.
    Le JS natif a tout ce que jQuery possède, sans la pile de plugins généralement mal maintenus et à moitié finis. Ces plugins font en général seulement ce qu’ils veulent faire, et pas grand-chose de plus.
    Les sélecteurs purs sont plus verbeux, mais n’importe quel éditeur de code correct vous permet de les saisir tout aussi vite. Je ne veux pas polémiquer, mais je ne comprends pas vraiment pourquoi autant de gens utilisent encore jQuery.
    https://youmightnotneedjquery.com/
  • Vu le profil des auteurs sur HN, ce n’est pas si surprenant.
    Dès qu’ils ont besoin d’un peu plus que de la sélection DOM, beaucoup prennent le gros framework JS à la mode du moment, comme ils l’ont toujours fait.
  • Ils disent « les gens qui voient jQuery comme une simple bibliothèque de sélection DOM », puis enchaînent en listant la sélection et des fonctions natives.
  • C’est beaucoup plus simple d’ajouter jQuery à un projet.
    Pas besoin d’outils de build ni des galères qui vont avec. React peut aussi fonctionner ainsi, mais les fonctionnalités proposées ne sont pas comparables.

• Dans un monde où beaucoup de gens cherchent activement à supprimer les dernières traces de jQuery, je me demande sincèrement qui développe encore activement avec jQuery aujourd’hui
  La plupart de ce qu’on faisait autrefois avec jQuery est désormais intégré aux navigateurs, et querySelectorAll me semble en être l’exemple le plus parlant

  • J’ai vieilli et les nouvelles technologies m’enthousiasment moins ; du coup, $.ajax() me paraît beaucoup plus simple que les promises, await et async du JS natif
    Pour m’y habituer, j’ai aussi utilisé du JS pur dans quelques petits projets perso, mais pour moi, gérer ça avec $.ajax() est quelque chose qui se fait immédiatement, comme de la mémoire musculaire
    En plus, il doit y avoir une vingtaine de personnes qui utilisent réellement le code que j’écris pour manipuler le DOM. Je ne suis pas responsable de l’UI, je suis côté backend, mais comme il n’y a personne pour le faire, j’écris aussi du frontend
  • D’après le sondage Stack Overflow de l’an dernier, jQuery était le troisième plus populaire
    https://survey.stackoverflow.co/2023/#section-most-popular-t...
  • Je viens de travailler dans une entreprise qui supprimait laborieusement les dernières traces de React pour les remplacer par HTMX
    Personnellement, je vois HTMX comme une sorte de successeur spirituel de jQuery
  • Moi aussi, je fais des efforts actifs pour supprimer jQuery, mais les gens se sont habitués à l’outil, et comme le réécrire coûte cher, il semble manquer de volonté ou de justification métier suffisante pour s’en débarrasser
    Je serais méfiant si un nouveau projet démarrait avec jQuery, mais il existe clairement des développeurs bien plus à l’aise avec la façon jQuery de faire les choses qu’avec du JavaScript pur
  • Il est utilisé par des développeurs solo ou de petites équipes qui détestent les toolchains modernes
    levelsio en est un bon exemple : https://twitter.com/levelsio/status/1750175827197567165
    Je suis aussi de ce côté-là et j’utilise toujours jQuery
    Mon SaaS actuel est une extension avec peu de code UI, https://www.snipcss.com, et mon prochain SaaS sera une extension d’automatisation web basée sur ChatGPT, avec pas mal d’UI. Les deux utilisent jQuery
    La principale raison pour laquelle je ne passe pas au JS pur avec querySelectorAll, c’est que j’aime la façon d’attacher les événements, notamment le fait de les attacher au parent pour cibler des éléments enfants ajoutés dynamiquement, que j’aime le chaînage de fonctions, et qu’il faut moins de code qu’en JS pur

• Excellent. Cela dit, j’ai tellement attendu la 4.0 que j’ai fini par créer mon propre jQuery, avec quelques différences clés
  Les animations, les tweens et les timelines utilisent du CSS pur au lieu du système personnalisé de jQuery, les éléments uniques et les listes sont gérés de façon transparente, et l’approche est inline

  • J’ai toujours pensé qu’il devrait exister ce genre d’alternative à jQuery moderne et légère. C’est bien fait et j’aime la syntaxe
    J’étais moi aussi en train d’implémenter quelque chose de similaire, incluant davantage que les événements inline et les méthodes de tableau standard [0]
    Ce serait bien d’avoir un article ou un screencast expliquant comment la locality of behavior est implémentée dans surreal et le projet associé css-scope-inline. J’aimerais le comprendre pour pouvoir le maintenir à long terme et l’intégrer aussi dans mes projets
    J’aimerais aussi discuter de philosophie du web. Je pense que nous serions assez alignés sur plusieurs points
    [0] https://hyperspace.so/All.js.png

• J’ai l’impression de revenir à mes années junior, vers 2008. J’avais eu un débat houleux avec mon tech lead pour ajouter jQuery au projet
  Son argument était que les 40 Ko de la bibliothèque minifiée représentaient une charge trop importante pour le temps de chargement de la page
  Ensuite, il a passé une semaine entière à écrire lui-même les appels Ajax et à tester la prise en charge sur plusieurs navigateurs, pour finalement échouer à le faire fonctionner dans Internet Explorer 5
  À l’époque, jQuery réglait vraiment beaucoup de casse-tête, et il a fini par ajouter la bibliothèque au projet

  • Les gens l’oublient souvent, mais les anciens navigateurs étaient très différents les uns des autres, et jQuery était le seul liant vraiment raisonnable pour maintenir une base de code dans ces conditions
  • Bravo au tech lead d’avoir mené le bon combat

• Bravo à l’équipe jQuery. Je pense que j’aimerai jQuery pour toujours
  C’est tout simplement un outil qui fait le boulot

  • Bootstrap, PHP, jQuery, WP, c’est la stack des gens qui produisent réellement des choses

• Avec le bien meilleur support des sélecteurs DOM dans les navigateurs aujourd’hui, je me demande pourquoi utiliser jQuery en 2024
  Je ne cherche pas à dénigrer, et je trouve ça chouette que le développement continue, mais je ne comprends pas bien quels sont les cas d’usage

  • Il y a plusieurs sélecteurs assez pratiques que document.querySelector() ne prend pas en charge
    Par exemple :selected, :checked, et quelques autres dont je ne me souviens plus mais que j’ai réellement rencontrés plusieurs fois
    Globalement, l’API DOM va à l’encontre de presque tout mon sens de ce qu’est une bonne conception d’API. J’ai aussi des reproches à faire à l’API jQuery, mais elle est bien meilleure, et le flux de lecture et d’écriture y est beaucoup plus naturel
  • Probablement à cause des projets legacy
    Je maintiens une vieille appli web .NET d’environ 15 ans et je reviens à jQuery. Rêver d’un refactoring complet ou d’une réécriture avec quelque chose de plus moderne comme les Web Components, c’est bien, mais en pratique, ça n’arrivera jamais
  • À mon avis, c’est grâce à l’API pratique et à l’immense écosystème
  • J’aime bien jQuery pour les pages d’administration
    Si c’est une page que seuls 20 employés en interne consultent, jQuery est suffisamment léger, peut être chargé directement depuis un CDN, ne nécessite aucune transpilation et couvre globalement tout ce dont on a besoin

• Pour info, nous avons construit tout l’éditeur drag-and-drop de notre plateforme low-code avec jQuery
  Cela inclut l’éditeur, tous les contrôles, donc les composants UI, et bien entendu le code final généré est lui aussi en pur jQuery
  Mais les dirigeants de grandes entreprises demandent souvent aux ingénieurs commerciaux pourquoi ce n’est pas React, Angular, etc.
  Je suis donc vraiment content de lire que jQuery reste aussi pertinent, et heureux que mon cofondateur et CTO ne cherche pas à changer de stack et continue de soutenir ce choix

• Je me souviens de l’époque où jQuery est apparu
  Pour convaincre mes collègues, j’avais organisé une présentation interne intitulée « Don’t Fear the $ », où j’expliquais les avantages qu’offrait jQuery

• Je me souviens de l’âge d’or de jQuery, quand on l’utilisait comme remplaçant de Mootools
  Comme beaucoup de gens passent de React à HTMX, peut-être qu’après avoir bouclé la boucle, on finira par voir le Web utiliser tout simplement du jQuery pur

  • J’ai traversé une époque similaire, mais ce bazar ne me manque pas
    Imaginer une application moderne avec accessibilité, prise en charge mobile, mises à jour en temps réel, visualisation, et même quelques fonctionnalités PWA, construite uniquement avec jQuery, ça sonne vraiment désagréable
    J’attends aussi que la surchauffe autour de HTMX se heurte à la réalité. Programmer une application avec de faux attributs façon DSL, je pense qu’on s’en lassera vite
  • HTMX me rappelle Mootools
    Une petite bibliothèque JS très spécialisée
  • HTMX ressemble à $().load()
  • « Beaucoup » est peut-être un peu exagéré