jQuery de John Resig a simplifié JavaScript, lissé les différences entre navigateurs et popularisé des patterns qui ont influencé les outils front‑end pendant des années. Voici comment il a façonné le web.
Si vous développiez un site entre 2005 et 2008, vous n’« écriviez » pas seulement du JavaScript. Vous négociiez avec les navigateurs.
Une fonctionnalité simple — surligner un élément de menu, afficher une modal, valider un formulaire, charger un extrait HTML sans rechargement complet — pouvait se transformer en petit projet de recherche. Vous cherchiez quelle méthode existait dans quel navigateur, quel événement se comportait différemment, et pourquoi cet appel DOM fonctionnait chez vous mais cassait pour la moitié des utilisateurs.
Les développeurs souhaitaient « écrire une fois, exécuter partout », mais les différences entre navigateurs donnaient plutôt l’impression de « coder trois fois, tester partout ». Internet Explorer avait ses bizarreries, d’anciennes versions de Firefox et Safari n’étaient pas d’accord sur certains cas limites, et même des bases comme la gestion des événements et la manipulation du DOM pouvaient être incohérentes.
Ce décalage ne faisait pas que perdre du temps — il changeait ce que les équipes osaient construire. L’UI interactive était possible, mais coûteuse en effort et fragile en maintenance. De nombreux sites restaient plus simples qu’ils ne le pouvaient parce que le coût d’assurer un fonctionnement correct sur tous les navigateurs était trop élevé.
jQuery, créé par John Resig, importait parce qu’il se concentrait sur les tâches du quotidien : sélectionner des éléments, réagir aux actions utilisateur, modifier la page, animer de petites transitions et faire des requêtes AJAX. Il offrait une API compacte et lisible qui lissait les différences entre navigateurs afin que vous passiez plus de temps à construire la fonctionnalité et moins de temps à lutter contre la plateforme.
En pratique, il rendait les interactions courantes simples et reproductibles — quelque chose qu’on pouvait enseigner, partager et réutiliser.
L’histoire n’est pas seulement que jQuery a fait gagner du temps. Il a influencé la façon de penser des développeurs : chaîner des opérations, s’appuyer sur des sélecteurs concis, organiser le code UI autour des événements et s’attendre à ce que les bibliothèques offrent une « expérience développeur » cohérente. Ces habitudes ont façonné les outils qui ont suivi, même après que les standards web aient rattrapé leur retard et que de nouveaux frameworks aient pris le relais.
Cet état d’esprit « faciliter le chemin le plus fréquent » est aussi visible dans les outils modernes. Des plateformes actuelles comme Koder.ai appliquent le même principe d’expérience développeur à un autre niveau — en permettant aux équipes de construire des apps web, backend et mobiles via un flux de travail piloté par chat — là où jQuery rendait autrefois le code UI côté navigateur accessible.
John Resig ne cherchait pas à lancer un mouvement quand il a commencé à bricoler une petite librairie JavaScript au milieu des années 2000. Il était un développeur qui ressentait la même friction que tout le monde : les choses simples sur le web prenaient trop de lignes de code, se cassaient dans certains navigateurs et étaient difficiles à expliquer aux coéquipiers.
La motivation principale de Resig était la clarté. Plutôt que d’obliger les développeurs à mémoriser des dizaines de bizarreries de navigateurs, il voulait un petit ensemble de commandes qui correspondaient à la façon dont les gens pensent la construction de pages : « trouve cet élément », « change ceci », « quand l’utilisateur clique, fais cela ». jQuery n’était pas conçu pour étaler de l’ingéniosité — il visait à réduire la frustration quotidienne et à aider les projets ordinaires à sortir.
L’empathie pour le développeur web type était tout aussi importante. La plupart des gens ne construisaient pas des démos expérimentales ; ils maintenaient des sites marketing, des panneaux d’administration et des pages produit sous contrainte de délai. L’accent mis par jQuery sur une API compacte et lisible reflétait cette réalité.
jQuery s’est répandu parce qu’il était facile à apprendre et à transmettre. Resig a donné des talks et des démos montrant des gains immédiats, et le projet a rapidement développé une réputation de bonne documentation et d’exemples accessibles. Quand un outil vous aide à résoudre un vrai problème en quelques minutes, vous le dites aux autres développeurs.
La communauté précoce a renforcé cette boucle. Les gens partageaient des extraits, écrivaient des plugins et signalaient des cas limites pour des navigateurs et appareils que Resig ne pouvait pas tester seul. jQuery a grandi en public, avec des retours qui ont déterminé ce qui devait rester simple et ce qu’il fallait adoucir.
Il est tentant de réduire jQuery à un unique « moment de génie », mais l’histoire plus honnête est celle de la persistance et du bon sens : repérer une douleur répandue, concevoir pour les flux de travail quotidiens et bâtir la confiance par la cohérence. Resig n’a pas seulement écrit du code — il a créé un outil qui ressemblait à un raccourci amical pour la façon dont le web fonctionnait réellement.
Avant jQuery, écrire un comportement interactif « simple » signifiait souvent assembler une pile d’astuces spécifiques aux navigateurs. On pouvait certes construire des interfaces riches, mais le coût était du temps, de la patience et beaucoup de tests.
Aujourd’hui, saisir un bouton et changer son texte paraît naturel en une ligne. À l’époque, la sélection DOM était incohérente et maladroite. Certains navigateurs supportaient des méthodes utiles, d’autres non, et on en venait à mélanger des approches comme getElementById, getElementsByTagName, des boucles manuelles et des vérifications de chaînes juste pour cibler les bons éléments.
Même lorsque vous sélectionniez ce dont vous aviez besoin, il fallait souvent écrire du code supplémentaire pour gérer les collections, les convertir en tableaux ou contourner des cas limites étranges.
Les gestionnaires de clics, les frappes clavier et les effets de survol étaient des besoins courants — mais les navigateurs n’étaient pas d’accord sur la façon dont la liaison d’événements fonctionnait et sur la forme de l’objet événement. Du code qui fonctionnait parfaitement dans un navigateur pouvait échouer silencieusement dans un autre.
Les développeurs écrivaient des wrappers pour normaliser la gestion des événements : « si cette API existe, utilise‑la ; sinon fais un fallback ». Ça signifiait plus de code, plus de débogage et plus de possibilités d’introduire des bugs.
Les requêtes asynchrones étaient possibles, mais peu conviviales. Mettre en place un XMLHttpRequest impliquait généralement plusieurs étapes, des logiques conditionnelles pour différents navigateurs et une gestion attentive des états de réponse.
Une petite fonctionnalité — soumettre un formulaire sans recharger la page — pouvait gonfler en dizaines de lignes avec retries, gestion des erreurs et tests de navigateurs.
La plus grosse douleur n’était pas d’écrire le code une fois ; c’était de le maintenir fonctionnel partout. Les équipes avaient besoin de quelque chose de fiable, facile à apprendre et suffisamment cohérent pour que de nouveaux développeurs puissent contribuer sans mémoriser une checklist de compatibilité navigateur. jQuery est arrivé comme la réponse à cette friction quotidienne.
La percée de jQuery n’était pas une nouvelle capacité du navigateur — c’était une nouvelle façon de penser le travail UI quotidien. Plutôt que d’écrire beaucoup de JavaScript spécifique au navigateur juste pour trouver un élément, le mettre à jour et connecter un événement, jQuery réduisait la routine à un simple pattern : trouver quelque chose, puis faire quelque chose.
Au centre se trouve la fonction $(). Vous lui passez un sélecteur de type CSS (ou un élément), et vous obtenez un objet jQuery — un wrapper facile à utiliser autour des éléments correspondants.
De là, vous appelez des méthodes qui ressemblent à des tâches : ajouter une classe, cacher un élément, changer du texte, attacher un gestionnaire de clic. Le but n’était pas d’exposer chaque détail bas niveau ; c’était de couvrir les 80 % des corvées UI que presque tous les sites nécessitaient.
jQuery encourageait un style fluide où chaque étape retourne le même objet jQuery, de sorte que vous pouvez « chaîner » des actions en une ligne lisible :
$(".notice")
.addClass("active")
.text("Saved!")
.fadeIn();
Même sans comprendre les internes, on comprenait l’histoire : trouver les notices, les marquer actives, définir le message, les afficher.
Avant jQuery, les développeurs demandaient constamment : « Quelle méthode marche dans ce navigateur ? » ou « Cette propriété s’appelle‑t‑elle différemment dans les vieilles versions ? ». jQuery répondait par un ensemble de méthodes cohérentes et un comportement prévisible. Les débutants avaient une montée en compétence douce sans être écrasés par les cas limites. Les pros gagnaient en vitesse : moins de fonctions utilitaires personnelles, moins de hacks de compatibilité et moins de code à relire.
Parce que l’API était compacte et que les noms de méthodes correspondaient aux intentions UI, jQuery incitait les équipes à écrire des scripts faciles à scanner. Plutôt que des appels DOM éparpillés et des variables temporaires, on lisait le code comme une séquence d’actions UI — rendant le travail front‑end plus proche d’assembler des étapes claires que de lutter avec le navigateur.
L’un des tours les plus persuasifs de jQuery était de rendre la première étape de toute tâche UI triviale : sélectionner les bons éléments. Plutôt que de se souvenir des méthodes DOM spécifiques à chaque navigateur et de leurs bizarreries, on écrivait quelque chose qui ressemblait au CSS et qui avait immédiatement du sens.
Les designers et front‑end pensaient déjà en sélecteurs : « prends toutes les .button dans l’en‑tête », « cible le premier élément », « trouve les inputs d’un certain type ». jQuery transforma ce modèle mental en outil JavaScript :
$(".nav a") pour travailler avec les liens de navigation$("#signup-form input[type=email]") pour trouver un champ précis$("ul li:first") pour une logique du « premier élément »Cette lisibilité comptait. Elle réduisait l’effort de traduction entre « ce que je veux » et « comment le DOM veut qu’on le demande ».
Derrière $(selector) se trouvait Sizzle, le moteur de sélecteurs de jQuery. Les anciens navigateurs n’étaient pas d’accord sur le comportement de certains sélecteurs, et certains ne supportaient pas l’ensemble complet. Sizzle fournissait une interprétation cohérente et des comportements de repli, si bien que $(".card > .title") ne devenait pas une loterie selon le navigateur.
Le résultat a été une vraie productivité : moins de branches conditionnelles, moins de « si IE alors… » et moins de temps passé à déboguer pourquoi un sélecteur matchait dans un navigateur mais pas dans un autre.
La puissance des sélecteurs cachait aussi des coûts :
Pour autant, pour le travail d’interface quotidien, rendre « trouver » simple était un énorme changement — et une grande partie de l’effet « super‑pouvoir » de jQuery.
Pour beaucoup de développeurs, jQuery n’était pas « une librairie » — c’était l’ensemble d’outils quotidien auquel on avait recours pour construire des interactions. Il transforma le travail UI courant en quelques appels prévisibles, même lorsque les navigateurs divergeaient sur les détails.
Avant jQuery, brancher un handler de clic pouvait signifier jongler avec différents modèles d’événements et des cas bizarres. .on() (et auparavant .bind()/.click()) offrait une manière cohérente d’écouter les actions utilisateur comme click, submit et les entrées clavier.
Il rendit aussi évident le « exécuter quand la page est prête » :
$(function () {
// safe to touch the DOM
});
Cette habitude unique réduisait les bugs de timing sur les pages typiques — plus besoin de se demander si les éléments existaient déjà.
L’API DOM de jQuery était volontairement petite et pratique. Besoin de mettre à jour du contenu ? .text() ou .html(). Besoin de construire des morceaux d’UI ? ('\u003cdiv\u003e...\u003c/div\u003e') et .append(). Besoin d’états visuels ? .addClass(), .removeClass() et .toggleClass().
Plutôt que de gérer les différences entre className, les bizarreries d’attributs et les méthodes de nœuds incohérentes, les développeurs pouvaient se concentrer sur ce qu’ils voulaient changer.
Les animations intégrées comme .hide(), .show(), .fadeIn() et .slideToggle() rendaient les pages vivantes avec peu d’effort. Les designers les adoraient, les parties prenantes les remarquaient et les tutoriels en faisaient un usage intensif.
Le revers : les effets étaient faciles à surutiliser — trop de fondus et de glissements pouvaient rendre une interface lente ou gadget. Néanmoins, pour des interactions typiques (menus, accordéons, notifications), jQuery abaissait la barrière pour « faire paraître l’ensemble soigné ».
À travers événements, modifications DOM et effets, le vrai gain était la simplicité : moins de cas limites dans le travail quotidien et un ensemble de patterns partagés que les équipes pouvaient apprendre rapidement.
Avant jQuery, « AJAX » sonnait comme une astuce : mettre à jour une partie d’une page sans recharger toute la page. En termes simples, c’est le navigateur qui envoie une requête en arrière‑plan, reçoit des données (souvent HTML ou JSON) puis met à jour la page pour que l’utilisateur puisse continuer.
XMLHttpRequest à la ligne uniqueLa fonctionnalité sous‑jacente était XMLHttpRequest, mais l’utiliser directement signifiait beaucoup de code répétitif : créer la requête, surveiller son état, parser les réponses, gérer les bizarreries des navigateurs.
jQuery enveloppait cette complexité dans des méthodes utilitaires qui semblaient des outils du quotidien :
$.ajax() pour le contrôle complet$.get() / $.post() pour des requêtes simples.load() pour récupérer du HTML et l’injecter dans un élémentAu lieu de câbler des handlers d’événements, construire des chaînes de requête et parser la réponse soi‑même, on pouvait se concentrer sur ce que l’utilisateur devait voir ensuite.
Ces patterns devinrent vite la norme :
Même avec un serveur vieillissant, jQuery permettait à l’interface de paraître réactive.
jQuery rendait les requêtes faciles à démarrer — pas toujours faciles à terminer correctement. Les erreurs courantes étaient :
L’API abaissait la barrière, mais enseignait aussi une leçon toujours valable : le « happy path » ne suffit pas pour construire une interface fiable.
jQuery n’était pas seulement une librairie à télécharger — c’était une plateforme sur laquelle on construisait. Les « plugins » étaient des petites extensions ajoutant des méthodes à jQuery, généralement via $.fn. Pour les développeurs, cela signifiait qu’on pouvait dropper une fonctionnalité et l’appeler avec le même style que tout le reste.
La barrière d’entrée était faible. Si vous connaissiez jQuery, vous compreniez déjà le pattern plugin : sélectionner des éléments, appeler une méthode, passer des options.
Tout aussi important, les conventions de jQuery rendaient les plugins étonnamment homogènes, même écrits par des auteurs différents :
$('.menu').dropdown() se lisait comme du jQuery natif.$('.btn').addClass('x').plugin().fadeIn().{ speed: 200, theme: 'dark' }, facile à copier et ajuster.Les plugins couvraient le « manque à mi‑parcours » entre le travail DOM brut et les frameworks applicatifs complets. Catégories communes : sliders et carousels, validation de formulaires, modals/lightboxes, sélecteurs de date, autocomplétion, tooltips et helpers de tableaux.
Pour beaucoup d’équipes, surtout celles travaillant sur des sites marketing ou des dashboards internes, les plugins transformaient des semaines de travail UI en une journée d’assemblage.
Le boom des plugins avait un coût. La qualité variait énormément, la documentation pouvait être mince et combiner plusieurs plugins menait parfois à des conflits CSS ou de handlers d’événements. La dépendance en chaîne devenait réelle : une fonctionnalité pouvait dépendre de deux autres plugins, chacun avec son historique de mise à jour. Quand les auteurs partaient, les plugins non maintenus pouvaient verrouiller un projet sur d’anciennes versions de jQuery — ou devenir un risque de sécurité et de stabilité.
Le cœur de jQuery rendait le travail DOM prévisible, mais les équipes devaient souvent construire les pièces d’interface elles‑mêmes. jQuery UI comblait ce vide avec un ensemble de composants prêts à l’emploi — datepickers, dialogues, onglets, sliders, accordéons, comportements draggable/sortable — packagés pour fonctionner à travers les navigateurs avec un minimum de tracas. Pour les petites équipes et agences livrant beaucoup de sites marketing ou d’outils internes, cette valeur « suffisant et rapide » était difficile à battre.
Le grand avantage n’était pas seulement les widgets — c’était la combinaison widgets + API cohérente + theming. On pouvait prototyper vite en ajoutant un dialogue ou une autocomplétion, puis l’habiller avec ThemeRoller plutôt que de réécrire le markup et les patterns CSS pour chaque projet. Cette répétabilité faisait de jQuery UI un kit pratique plutôt qu’un simple ensemble de composants.
jQuery Mobile tentait de résoudre un autre problème : les premiers smartphones avaient des capacités de navigateur incohérentes et un support CSS limité, et les conventions du responsive n’étaient pas encore établies. Il proposait des composants tactiles et un modèle de navigation « page unique » avec transitions AJAX, visant à faire qu’une base de code se comporte de manière un peu native.
À mesure que les standards web se sont améliorés — CSS3, navigateurs mobiles plus performants et primitives natives de contrôle et layout — certaines de ces abstractions sont devenues plus coûteuses qu’utiles. Les widgets jQuery UI pouvaient être lourds, plus difficiles à rendre accessibles et compliqués à aligner avec des attentes de design modernes. Le ré‑écriture DOM et le modèle de navigation de jQuery Mobile s’opposaient aussi à des approches ultérieures comme les layouts responsive et le routing piloté par frameworks.
Pourtant, ces projets ont prouvé une idée clé : des composants UI réutilisables et partagés accélèrent dramatiquement la mise en production.
jQuery n’a pas seulement rendu les navigateurs plus prévisibles ; il a changé l’apparence du code front‑end « normal ». Les équipes ont commencé à écrire du JavaScript tous les jours, pas seulement pour des pages particulières, parce que les tâches UI courantes devenaient prévisibles.
Un des plus grands changements culturels apportés par jQuery a été la popularisation du chaining : sélectionner quelque chose, puis continuer à opérer dessus dans un flux lisible.
$(".card")
.addClass("active")
.find(".title")
.text("Updated")
.end()
.fadeIn(200);
Ce style fluide a influencé des bibliothèques ultérieures et même des APIs natives modernes. Il a aussi poussé les développeurs vers de petites opérations composables plutôt que de grosses fonctions monolithiques.
Les helpers jQuery — $.each, $.map, $.extend, les raccourcis AJAX — donnaient envie de compresser la logique en moins de lignes. Cela améliorait la vélocité, mais encourageait aussi des one‑liners « malins » et des comportements implicites difficiles à reprendre des mois plus tard.
Beaucoup de bases de code ont fini par mélanger logique métier directement dans des handlers de clics, parce qu’il était si simple de « le faire ici ». Cette commodité a accéléré la livraison, mais augmenté la complexité à long terme.
Avant que les composants et modèles d’état prévisibles deviennent courants, les applications jQuery stockaient souvent l’état dans le DOM : classes, inputs cachés et attributs data. Le débogage passait par l’inspection du HTML vivant et le pas‑à‑pas dans des callbacks d’événements qui pouvaient se déclencher dans un ordre surprenant.
Les tests unitaires étaient possibles, mais on se reposait plus souvent sur la QA manuelle et les devtools du navigateur. Les problèmes étaient fréquemment liés au timing (animations, AJAX, bubbling), rendant les bugs intermittents.
Le code jQuery restait maintenable quand les équipes :
Il devenait embrouillé quand les pages accumulaient des couches de handlers, répétaient des sélecteurs partout et ajoutaient « juste encore un » tweak dans un callback d’animation. La librairie facilitait l’itération rapide ; la discipline déterminait si le résultat vieillissait bien.
jQuery n’a pas disparu du jour au lendemain, et il n’a pas « perdu » parce qu’il était devenu mauvais. Il s’estompa parce que la plateforme navigateur n’avait plus besoin d’un traducteur. Les problèmes que jQuery lissait — APIs manquantes, comportements incohérents et flux de travail maladroits — sont devenus moins fréquents à mesure que les standards ont mûri et que les navigateurs ont convergé.
Au fur et à mesure que le DOM et les APIs JavaScript se standardisaient, beaucoup d’appels jQuery du quotidien ont trouvé des équivalents directs :
document.querySelector() et document.querySelectorAll() couvrent la plupart des cas qui nécessitaient autrefois $(...).addEventListener() est devenu universellement fiable.fetch() (et plus tard async/await) a rendu les appels de type AJAX natifs et lisibles.Quand la « façon native » est cohérente entre navigateurs, la raison de dépendre d’un helper tiers diminue.
Alors que les apps web passaient de quelques widgets interactifs à des produits complets, les équipes se sont mises à surveiller le temps de chargement et le coût en JS. Livrer jQuery (plus plugins) pour quelques commodités devenait plus difficile à justifier — surtout sur des réseaux mobiles.
Ce n’était pas que jQuery était lent ; c’est que « encore une dépendance » devenait un véritable compromis. Les développeurs ont préféré de plus en plus des utilitaires ciblés et légers — ou rien du tout quand la plateforme faisait déjà le travail.
Les frameworks single‑page ont déplacé l’attention loin de la manipulation manuelle du DOM vers la gestion d’état et la composition UI à partir de composants. En React/Vue/Angular, on ne demande généralement pas à la page « trouve cet élément et change‑le ». On met à jour les données, et l’UI se ré‑rendra.
Dans ce modèle, les forces de jQuery — manipulation DOM impérative, effets et wiring ponctuel d’événements — sont moins centrales, voire parfois déconseillées.
La mission de jQuery était de rendre le web utilisable et cohérent. Quand les navigateurs ont rattrapé leur retard, jQuery est devenu moins nécessaire — pas moins important. De nombreux sites de production l’utilisent encore, et beaucoup d’APIs modernes (et les attentes des développeurs) reflètent les leçons que jQuery a enseignées à l’écosystème.
jQuery n’est plus le choix par défaut pour le nouveau travail front‑end, mais il alimente encore discrètement une part importante du web — et son influence est imprimée dans la façon dont beaucoup de développeurs pensent JavaScript.
On rencontre jQuery surtout là où la stabilité prime sur la réécriture :
Si vous maintenez l’un de ces projets, l’avantage est la prévisibilité : le code est compréhensible, bien documenté et généralement facile à patcher.
Les outils modernes n’ont pas copié jQuery à la lettre, mais ils ont absorbé ses meilleurs instincts :
Même l’évolution du JS pur (querySelectorAll, classList, fetch, meilleure gestion des événements) reflète les problèmes que jQuery a résolus pour les développeurs du quotidien.
La plus grande leçon est une pensée produit : une petite API cohérente assortie d’une excellente documentation peut changer la façon dont une industrie entière écrit du code.
C’est aussi un rappel que l’expérience développeur se cumule. À l’époque de jQuery, la DX consistait à cacher les bizarreries du navigateur derrière une API propre ; aujourd’hui, cela peut aussi signifier compresser le chemin de l’idée au logiciel fonctionnel. C’est en partie pourquoi des plateformes vibe‑coding comme Koder.ai parlent à beaucoup d’équipes : au lieu d’assembler du boilerplate à la main, on itère dans une interface de chat, on génère un front React avec un backend Go + PostgreSQL (ou une app mobile Flutter), et on avance — tout en conservant l’option d’exporter le code source quand on veut le contrôle total.
jQuery comptait parce qu’il transformait le scripting DOM, incohérent et spécifique aux navigateurs, en un ensemble d’outils petit et prévisible. Il rendait les tâches quotidiennes — sélectionner des éléments, attacher des événements, modifier le DOM, faire de l’AJAX — répétables d’un navigateur à l’autre, ce qui augmentait la vitesse et la confiance des équipes.
Avant jQuery, les développeurs rencontraient régulièrement des différences inter‑navigateurs dans :
XMLHttpRequest et cas limites)Le coût principal n’était pas d’écrire du code une fois, mais de le maintenir fiable partout.
$() est la fonction centrale : vous lui passez un sélecteur de type CSS (ou un élément) et vous obtenez un objet jQuery qui enveloppe les éléments correspondants. Cet objet expose un ensemble cohérent de méthodes pour « trouver, puis agir » sans vous soucier des bizarreries des navigateurs.
Le chaining tient au fait que la plupart des méthodes jQuery retournent le même objet jQuery après avoir effectué une action. Cela permet d’exprimer une séquence d’opérations UI lisible en une seule suite (sélection → modification → animation) sans variables temporaires excessives.
Sizzle est le moteur de sélection derrière $(selector). Il fournissait un comportement de sélecteur cohérent et un support élargi à une époque où les navigateurs divergeaient sur ce qu’ils supportaient et comment ils interprétaient certains cas limites.
jQuery a normalisé les tâches d’événements courantes pour éviter d’écrire des branches spécifiques à chaque navigateur. Il a aussi popularisé des motifs pratiques comme exécuter du code quand le DOM est prêt :
$(function () {
// safe to touch the DOM
});
Cela a réduit les bugs liés au timing sur les pages typiques.
Les helpers AJAX de jQuery ont encapsulé les parties répétitives de XMLHttpRequest et rendu les cas courants simples :
$.ajax() pour le contrôle complet$.get() / $.post() pour les requêtes simples.load() pour récupérer du HTML et l’injecter dans un élémentLes plugins étendaient jQuery en ajoutant des méthodes (souvent via $.fn) pour que les fonctionnalités se comportent comme des appels jQuery natifs. Cela rendait très simple l’ajout de capacités UI courantes (modals, validation, sliders) en réutilisant un modèle familier : sélecteurs + objets d’options + chaining.
jQuery a décliné principalement parce que les navigateurs ont standardisé les fonctionnalités qu’il masquait :
querySelector(All) a réduit le besoin d’aides aux sélecteursaddEventListener() est devenu fiable partoutfetch() + async/await a rendu le code réseau plus lisibleAvec l’importance croissante de la taille des bundles et des performances, embarquer jQuery pour quelques commodités est devenu plus difficile à justifier.
Ne réécrivez pas juste pour le retirer. Approche pratique :
jQuery est souvent défendable dans les applications legacy, les thèmes/plugins CMS anciens et les petites améliorations « déjà sur la page ».
Il a abaissé la barrière pour construire des interfaces réactives, mais il fallait tout de même prévoir une gestion d’erreurs solide et un retour utilisateur clair.