John Resig et jQuery : la bibliothèque qui a façonné le front‑end

Pourquoi jQuery a tant compté

À quoi ressemblait la création de sites au milieu des années 2000

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.

Le problème du « écrire une fois, exécuter partout »

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é.

La promesse de jQuery : simplifier le travail UI quotidien

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.

Ce sur quoi se concentre cet article

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 : la personne derrière le projet

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.

Un objectif pratique : rendre les tâches courantes évidentes

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é.

Partager tôt, écouter souvent

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.

Pas d’idolâtrie — juste de bons instincts produit

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.

Le web avant jQuery : vrais points de douleur

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.

Trouver des éléments était plus difficile qu’il n’y paraît

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 événements = casse‑tête inter‑navigateurs

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.

L’AJAX donnait l’impression d’être réservé aux experts

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.

Le vrai coût : fiabilité et vitesse d’équipe

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 grande idée : une API petite pour les tâches UI courantes

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.

« Trouver, puis agir »

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.

Le chaining : moins de variables, une intention plus claire

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.

Pourquoi une API petite et cohérente importait

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.

Des scripts centrés sur les tâches devinrent la norme

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.

Sélecteurs et Sizzle : « trouver » est devenu facile

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 sélecteurs CSS comme modèle mental familier

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 ».

Ce que Sizzle faisait (et pourquoi ça comptait)

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.

Les compromis : commodité vs complexité cachée

La puissance des sélecteurs cachait aussi des coûts :

• Les sélecteurs coûteux pouvaient nuire aux performances, surtout s’ils étaient évalués souvent (par exemple dans des handlers de scroll ou resize).
• Il devenait facile de sur‑sélectionner, puis de « corriger plus tard » avec du chaining — un code propre en apparence qui faisait plus de travail qu’on ne le réalisait.
• S’appuyer sur des sélecteurs complexes encourageait parfois un couplage fort du comportement JS à une structure DOM fragile.

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.

Événements, modifications du DOM et effets : la boîte à outils quotidienne

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.

Des événements sans surprises navigateur

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à.

Une manipulation du DOM que l’on pouvait mémoriser

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.

Des effets qui vendaient l’interaction (parfois un peu trop)

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.

L’AJAX rendu abordable

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.

De XMLHttpRequest à la ligne unique

La 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ément

Au 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.

Usages quotidiens qui paraissaient « modernes »

Ces patterns devinrent vite la norme :

• Suggestions de recherche pendant la saisie (récupérer une petite liste, l’afficher sous l’input)
• Soumissions de formulaires sans changer de page (envoyer les champs, afficher succès ou erreurs en ligne)
• Dashboards qui rafraîchissent des parties de l’UI (polling, remplacement d’un tableau, mise à jour de compteurs)

Même avec un serveur vieillissant, jQuery permettait à l’interface de paraître réactive.

Où l’on butait

jQuery rendait les requêtes faciles à démarrer — pas toujours faciles à terminer correctement. Les erreurs courantes étaient :

• Gestion d’erreurs faible : supposer le succès et ignorer les timeouts, erreurs serveur ou JSON mal formé
• Conditions de course : plusieurs requêtes retournant dans le désordre et écrasant l’UI
• Échecs silencieux : aucun retour utilisateur quand le réseau tombe

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.

Les plugins : l’écosystème qui a multiplié la puissance de jQuery

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.

Pourquoi les plugins se sont propagés si vite

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 :

• Nommage : $('.menu').dropdown() se lisait comme du jQuery natif.
• Chaining : les bons plugins retournaient la sélection originale pour continuer la chaîne : $('.btn').addClass('x').plugin().fadeIn().
• Objets d’options : la configuration ressemblait souvent à { speed: 200, theme: 'dark' }, facile à copier et ajuster.

À quoi on les utilisait

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.

Les compromis

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é.

jQuery UI et jQuery Mobile : des composants pour les masses

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.

Pourquoi jQuery UI était un cheat code productivité

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.

Le pari de jQuery Mobile sur un web mobile chaotique

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.

Pourquoi une partie a mal vieilli

À 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.

Comment jQuery a changé les habitudes de codage front‑end

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.

APIs fluides et habitude du chaining

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.

« Faire plus avec moins de code » (et les compromis)

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.

Tests et débogage à l’ère du DOM direct

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.

Quand jQuery restait propre vs quand il devenait embrouillé

Le code jQuery restait maintenable quand les équipes :

• gardaient les requêtes DOM près des éléments qu’elles affectaient
• utilisaient de petites fonctions et la délégation d’événements
• traitaient les plugins comme des blocs réutilisables

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.

Pourquoi jQuery s’estompa : les standards ont mûri

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é.

Le navigateur a commencé à copier les meilleures idées

Au fur et à mesure que le DOM et les APIs JavaScript se standardisaient, beaucoup d’appels jQuery du quotidien ont trouvé des équivalents directs :

• Sélection d’éléments : document.querySelector() et document.querySelectorAll() couvrent la plupart des cas qui nécessitaient autrefois $(...).
• Événements : addEventListener() est devenu universellement fiable.
• Requêtes réseau : 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.

Les performances et la taille des bundles ont gagné en importance

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 SPA ont redéfini le travail front‑end

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.

Prendre du recul : jQuery a si bien réussi qu’il s’est rendu optionnel

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.

L’héritage : ce que jQuery nous a laissé

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.

Où jQuery apparaît encore

On rencontre jQuery surtout là où la stabilité prime sur la réécriture :

• Applications métiers legacy créées pendant le pic de jQuery et qui fonctionnent toujours
• Thèmes et plugins CMS (surtout dans des anciennes installations WordPress)
• Scripts « correctifs rapides » sur des pages marketing : un slider ici, une modal là

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.

Des idées qui ont survécu à la librairie

Les outils modernes n’ont pas copié jQuery à la lettre, mais ils ont absorbé ses meilleurs instincts :

• APIs ergonomiques : accomplir des tâches courantes avec quelques appels lisibles
• Les sélecteurs comme concept central : « trouver des éléments, puis agir » est devenu standard
• Extensibilité : l’esprit plugin vit dans les écosystèmes de paquets et les patterns de composants

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.

Ce qu’on peut retenir de jQuery aujourd’hui

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.

Choisir le bon outil aujourd’hui

• Pour du nouveau travail, préférez les APIs DOM modernes et les patterns natifs des frameworks.
• Pour du code jQuery existant, ne réécrivez pas par principe — refactorez quand cela réduit le risque ou le coût.
• Pour petits comportements UI ponctuels, le JS natif suffit généralement ; jQuery peut rester un raccourci pragmatique s’il est déjà chargé.