jQuery a simplifié JavaScript en rendant le DOM, les événements et l'AJAX plus faciles. Découvrez ce que c'est, pourquoi il a décliné et quand il reste pertinent aujourd'hui.
jQuery est une petite bibliothèque JavaScript qui rend les tâches courantes sur une page web plus simples — comme sélectionner des éléments, réagir à des clics, changer du texte, afficher/masquer des parties de la page et envoyer des requêtes à un serveur.
Si vous avez déjà vu du code comme $("button").click(...), c'est jQuery. Le $ est simplement un raccourci pour « trouver quelque chose sur la page et faire quelque chose avec ».
Ce guide est pratique et non technique : ce qu'est jQuery, pourquoi il est devenu populaire, pourquoi les projets récents y recourent moins souvent, et comment le gérer si votre site l'utilise encore. Il est volontairement plus long afin d'inclure des exemples clairs et des conseils concrets plutôt que des opinions rapides.
Quand on dit que jQuery est « oublié », on ne veut généralement pas dire qu'il a disparu. On veut dire :
Donc l'histoire n'est pas « jQuery est mort ». C'est plutôt : jQuery est passé d'outil par défaut pour le front-end à dépendance héritée que vous pouvez hériter — et que vous choisissez parfois encore en connaissance de cause.
Avant jQuery, le travail front‑end consistait souvent à réécrire les mêmes petits bouts de code ennuyeux encore et encore — puis à les tester dans plusieurs navigateurs et constater qu'ils se comportaient différemment. Même des objectifs simples comme « trouver cet élément », « attacher un gestionnaire de clic » ou « envoyer une requête » pouvaient se transformer en une montagne de cas particuliers.
Beaucoup de JavaScript ancien consistait moins à construire des fonctionnalités et plus à lutter contre l'environnement. Vous écriviez du code qui fonctionnait dans un navigateur, puis ajoutiez des branches pour qu'il fonctionne dans un autre. Les équipes conservaient leurs « mini bibliothèques » internes de fonctions utilitaires juste pour survivre aux changements quotidiens de l'interface.
Le résultat : un développement plus lent, plus de bugs et la crainte permanente qu'un petit changement casse un navigateur ancien sur lequel vos utilisateurs comptaient.
Les navigateurs n'étaient pas d'accord sur des détails importants. Les méthodes de sélection du DOM, la gestion des événements et même la façon d'obtenir la taille d'un élément pouvaient varier. Internet Explorer, en particulier, avait des API différentes pour les événements et les requêtes XMLHTTP, donc le code « standard » n'était pas toujours vraiment portable.
C'était important parce que les sites n'étaient pas développés pour un seul navigateur. Si votre formulaire de paiement, votre menu de navigation ou votre dialogue modal ne fonctionnait pas dans un navigateur populaire, c'était un vrai problème business.
jQuery est devenu important parce qu'il offrait une API cohérente et conviviale qui lissait ces différences.
Il rendait les tâches courantes beaucoup plus simples :
Tout aussi important, le style « écrire moins, faire plus » de jQuery a aidé les équipes à livrer plus vite avec moins de surprises spécifiques aux navigateurs — surtout à une époque où les « API DOM modernes » n'étaient pas aussi capables ou largement supportées qu'aujourd'hui.
La vraie force de jQuery n'était pas d'introduire des idées complètement nouvelles : c'était de rendre les tâches courantes du navigateur cohérentes et faciles à travers différents navigateurs. Si vous lisez du code front‑end ancien, vous verrez typiquement jQuery utilisé pour quatre usages quotidiens.
$)La fonction $() permettait de « saisir » des éléments avec des sélecteurs de type CSS et ensuite de travailler avec eux en groupe.
Au lieu de jongler avec des bizarreries de navigateurs et des API verbeuses, vous pouviez sélectionner tous les éléments, trouver un enfant ou remonter jusqu'au parent avec des appels courts et chaînables.
jQuery a rendu simple la réaction aux actions utilisateur :
click pour les boutons et lienssubmit pour les formulairesready pour exécuter du code quand la page est chargéeIl lissait aussi les différences dans la façon dont les navigateurs géraient les objets événementiels et le binding, ce qui comptait beaucoup quand le support navigateur était inégal.
Avant que fetch() soit standard, $.ajax(), $.get() et $.post() de jQuery étaient un moyen simple de demander des données au serveur et de mettre à jour la page sans rechargement.
Ça a permis des patterns maintenant normaux — recherche en direct, boutons « charger plus », mises à jour partielles — en utilisant une API unique et familière.
jQuery a démocratisé des touches UI rapides comme hide(), show(), fadeIn(), slideToggle() et animate(). Pratique pour les menus, notifications et transitions basiques — surtout quand le support CSS était moins fiable.
Pris ensemble, ces facilités expliquent pourquoi le JavaScript legacy commence souvent par $( et pourquoi jQuery est resté l'outil par défaut si longtemps.
Une grande partie de la réputation de jQuery vient de la concision de code pour des tâches UI courantes — surtout quand les différences entre navigateurs rendaient la vie difficile. Un rapide face‑à‑face le montre bien.
jQuery
// Select a button and run code when it's clicked
$('#save').on('click', function (e) {
e.preventDefault();
$('.status').text('Saved!');
});
JavaScript moderne (vanilla)
// Select a button and run code when it's clicked
const saveButton = document.querySelector('#save');
const status = document.querySelector('.status');
saveButton?.addEventListener('click', (e) => {
e.preventDefault();
if (status) status.textContent = 'Saved!';
});
À première vue, la version jQuery paraît « plus propre » : une seule chaîne sélectionne l'élément, attache un handler et met à jour le texte. Cette compacité a été un argument majeur.
Le JavaScript moderne est un peu plus verbeux, mais aussi plus explicite :
querySelector et addEventListener disent exactement ce qui se passe.textContent est une propriété DOM standard (pas d'enveloppe de bibliothèque).?.) et les vérifications nulles clarifient ce qui arrive si les éléments n'existent pas.Cela dépend du contexte. Si vous maintenez une base de code ancienne qui utilise jQuery partout, le snippet jQuery peut être plus cohérent et plus rapide à manier. Si vous écrivez du neuf, les API DOM modernes sont largement supportées, réduisent les dépendances et s'intègrent mieux avec les outils et frameworks actuels.
Pendant longtemps, le principal avantage de jQuery était la prévisibilité. On pouvait écrire d'une manière pour sélectionner, attacher des événements ou faire une requête — et ça marchait presque partout.
Au fil des années, les navigateurs se sont normalisés et améliorés. Beaucoup des commodités « indispensables » que regroupait jQuery sont maintenant intégrées à JavaScript, si bien qu'on n'a souvent plus besoin d'une bibliothèque supplémentaire pour les bases.
Les méthodes DOM modernes couvrent la plupart des patterns jQuery courants :
document.querySelector() / document.querySelectorAll() remplacent $(...) pour de nombreuses sélections.element.classList.add() / .remove() / .toggle() couvrent la manipulation de classes.element.addEventListener() remplace l'enveloppe d'événements de jQuery pour la plupart des cas.Au lieu de retenir des helpers spécifiques à jQuery, vous pouvez compter sur des API standard qui fonctionnent sur les navigateurs modernes.
Là où $.ajax() était une solution courante, fetch() gère désormais de nombreuses requêtes quotidiennes avec moins de cérémonial, surtout associé au JSON :
const res = await fetch('/api/items');
const data = await res.json();
Il faut toujours gérer explicitement erreurs et timeouts, mais l'idée centrale — faire des requêtes sans plugin — est maintenant native.
jQuery a initié beaucoup de personnes à l'asynchrone via des callbacks et $.Deferred. Aujourd'hui, les Promises et async/await rendent les flux asynchrones plus lisibles, et les modules ES clarifient l'organisation du code.
Cette combinaison — API DOM modernes + fetch + fonctionnalités modernes du langage — a supprimé une grande partie de la raison originelle pour laquelle les équipes choisissaient systématiquement jQuery.
jQuery a grandi à l'époque des « sites multi‑pages » : le serveur rendait le HTML, le navigateur chargeait une page, et vous ajoutiez du comportement — gestionnaires de clics, animations, appels AJAX — au markup existant.
Les frameworks modernes ont renversé ce modèle. Plutôt que d'enrichir des pages, les apps génèrent souvent la majorité de l'UI côté navigateur et la gardent synchronisée avec les données.
React, Vue et Angular ont popularisé l'idée d'interfaces construites en composants — petites pièces réutilisables qui possèdent leur markup, comportement et état.
Dans ce modèle, le framework veut être la source de vérité pour ce qui s'affiche. Il suit l'état, rerend des portions de l'UI quand l'état change, et attend que vous exprimiez les changements de manière déclarative (« quand X est vrai, afficher Y »).
jQuery, en revanche, encourage la manipulation impérative du DOM (« trouve cet élément, change son texte, masque‑le »). Cela peut entrer en conflit avec le cycle de rendu d'un framework. Si vous modifiez manuellement des nœuds DOM contrôlés par un composant, le rendu suivant peut écraser vos changements — ou vous amener à déboguer des incohérences.
Avec la montée des SPA, les équipes ont adopté des outils de build et bundlers (Webpack, Rollup, Vite). Au lieu d'inclure quelques balises script, vous importez des modules, bundlez ce que vous utilisez et optimisez la performance.
Ce changement a rendu les équipes plus sensibles aux dépendances et à la taille des bundles. Inclure jQuery « au cas où » est devenu moins naturel quand chaque kilo‑octet et chaque mise à jour tierce fait partie du pipeline.
On peut utiliser jQuery dans un framework, mais cela devient souvent une île à part — plus difficile à tester, plus difficile à raisonner et plus susceptible de casser lors de refactors. Beaucoup d'équipes ont donc choisi les patterns natifs au framework plutôt que le scripting DOM à la jQuery.
jQuery en lui‑même n'est pas « énorme », mais il arrive souvent avec du bagage. De nombreux projets qui reposent sur jQuery accumulent aussi des plugins (sliders, datepickers, lightboxes, validateurs), chacun ajoutant du code tiers à télécharger et analyser. Avec le temps, une page peut finir par expédier plusieurs utilitaires redondants — surtout quand des fonctionnalités ont été ajoutées rapidement et jamais revues.
Plus de JavaScript signifie généralement plus à récupérer, parser et exécuter avant que la page ne devienne réactive. Cet effet se ressent davantage sur mobile, réseaux lents et matériels anciens. Même si l'expérience finale est fluide, le « temps jusqu'à utilisable » peut souffrir quand la page attend des scripts supplémentaires et leurs dépendances.
Un pattern courant dans les sites de longue vie est la base de code hybride : certaines fonctionnalités écrites en jQuery, des parties plus récentes construites avec un framework (React, Vue, Angular), et quelques snippets en JavaScript natif. Ce mélange peut devenir confus :
Quand plusieurs styles coexistent, les petits changements deviennent plus risqués. Un développeur met à jour un composant, mais un vieux script jQuery intervient sur le même markup et provoque des bugs difficiles à reproduire.
Les équipes s'éloignent progressivement de jQuery non pas parce qu'il « cesse de fonctionner », mais parce que les projets modernes optimisent la taille des bundles et la clarté de la propriété du comportement UI. En grandissant, réduire le code tiers et standardiser sur une approche facilite généralement l'optimisation des performances, le débogage et l'onboarding.
jQuery n'a pas seulement été populaire — il est devenu par défaut. Pendant des années, c'était la façon la plus simple de rendre des pages interactives fiables à travers les navigateurs, si bien qu'il s'est retrouvé intégré dans d'innombrables templates, snippets, tutoriels et solutions copy‑paste.
Une fois cela arrivé, jQuery est devenu difficile à éviter : même si un site n'utilisait qu'une petite fonctionnalité, il chargeait souvent toute la bibliothèque parce que le reste supposait sa présence.
Une grande raison pour laquelle jQuery apparaît encore est simple : son succès l'a rendu omniprésent dans le code tiers. De vieux widgets UI, sliders, lightboxes, validateurs de formulaires et scripts de thème étaient souvent écrits comme plugins jQuery. Si un site dépend d'un de ces composants, retirer jQuery peut signifier réécrire ou remplacer cette dépendance — pas seulement changer quelques lignes.
WordPress est une grosse source de « jQuery legacy ». Beaucoup de thèmes et plugins — surtout ceux créés il y a des années — utilisent jQuery pour le front‑end et, historiquement, les écrans d'administration WordPress s'appuyaient aussi sur lui. Même si les versions récentes vont vers du JavaScript moderne, la longue traîne d'extensions existantes maintient jQuery présent sur de nombreuses installations.
Les sites anciens préfèrent souvent « ne pas casser ce qui marche ». Garder jQuery peut être l'option la plus sûre quand :
En bref, jQuery n'est pas toujours « oublié » — il fait souvent partie des fondations sur lesquelles un site a été construit, et on ne remplace pas une fondation à la légère.
jQuery n'est pas un mauvais logiciel — il est simplement moins nécessaire qu'avant. Il existe encore des situations réelles où garder (ou même ajouter) un peu de jQuery est le choix le plus pragmatique, notamment quand on optimise pour le temps, la compatibilité ou la stabilité plutôt que pour la pureté architecturale.
Si vos exigences incluent des navigateurs anciens (en particulier d'anciennes versions d'Internet Explorer), jQuery peut encore simplifier la sélection du DOM, la gestion d'événements et l'AJAX d'une manière que les APIs natives ne couvrent pas sans polyfills supplémentaires.
La question clé est le coût : supporter des navigateurs anciens implique généralement d'expédier du code en plus. Dans ce contexte, jQuery peut faire partie du package de compatibilité acceptable.
Si un site est déjà construit autour de jQuery, de petites modifications UI sont souvent plus rapides et plus sûres si elles restent dans le même style que le reste du code. Mélanger les approches peut créer de la confusion (deux patterns pour les événements, deux façons de manipuler le DOM), ce qui complique la maintenance.
Une règle raisonnable : si vous touchez une ou deux pages et que l'application est par ailleurs stable, réparer avec jQuery est correct — évitez simplement d'étendre l'utilisation de jQuery à de nouveaux « systèmes » que vous devrez ensuite démêler.
Pour un site marketing simple ou un outil interne — pas de bundler, pas de transpileur, pas de framework de composants — jQuery peut rester un aide pratique via une seule balise script. Utile quand vous voulez quelques interactions (menus basculants, comportements de formulaire simples) et que vous préférez ne pas introduire une chaîne de build.
De nombreux plugins matures (datepickers, tableaux, lightboxes) ont été construits sur jQuery. Si un plugin ancien est critique pour l'activité et stable, garder jQuery comme dépendance peut être l'option à plus faible risque.
Avant de vous engager, vérifiez s'il existe une alternative non‑jQuery maintenue — ou si la mise à jour du plugin nécessiterait une réécriture plus large que le projet ne peut se permettre.
S'éloigner de jQuery est moins une grande réécriture qu'une réduction progressive de la dépendance sans casser les comportements dont dépendent les utilisateurs. L'approche la plus sûre est itérative : garder les pages fonctionnelles tout en remplaçant les pièces en dessous.
Commencez par répondre à trois questions pratiques :
Cet audit vous aide à éviter de remplacer des choses dont vous n'avez pas besoin et à repérer des dépendances cachées comme un plugin qui utilise discrètement $.ajax().
La plupart des équipes obtiennent des gains rapides en remplaçant les patterns les plus simples :
$(".card") → document.querySelectorAll(".card").addClass() / .removeClass() → classList.add() / classList.remove().on("click", ...) → addEventListener("click", ...)Faites cela en petites PR pour faciliter la revue et le rollback.
Si vous utilisez $.ajax(), migrez ces appels vers fetch() (ou un petit helper HTTP) endpoint par endpoint. Conservez les formes de réponse identiques pour que le reste de l'UI n'ait pas à changer immédiatement.
// jQuery
$.ajax({ url: "/api/items", method: "GET" }).done(renderItems);
// Modern JS
fetch("/api/items")
.then(r => r.json())
.then(renderItems);
Avant de supprimer jQuery, ajoutez de la couverture là où c'est important : parcours utilisateurs clés, envois de formulaires et tout UI dynamique. Même des vérifications légères (tests smoke Cypress ou une checklist QA) peuvent attraper des régressions tôt. Déployez les changements derrière un feature flag quand possible et confirmez que les métriques/erreurs restent stables.
Si vous voulez plus de sécurité pendant les refactors, utilisez des outils qui supportent snapshots et rollback. Par exemple, des équipes qui modernisent des front ends legacy prototypent parfois des remplacements dans Koder.ai (une plateforme de « vibe‑coding » pour construire des apps web via chat) et utilisent son flux snapshot/rollback pour itérer sans perdre une version « connue bonne ».
Si vous avez besoin d'aide pour organiser le plan global, voyez /blog/jquery-vs-vanilla-js pour un comparatif que vous pouvez utiliser pendant les refactors.
Migrer hors de jQuery concerne souvent moins la « syntaxe » que le démêlage d'années d'hypothèses. Voici les pièges qui ralentissent les équipes — et comment les éviter.
Une réécriture totale paraît propre, mais crée souvent une branche longue, beaucoup de régressions et la pression de livrer un travail inachevé. Une approche plus sûre est incrémentale : remplacez une fonctionnalité ou une page à la fois, conservez le comportement identique et ajoutez des tests autour des morceaux touchés.
Si vous introduisez React/Vue/Svelte (ou même un système de composants léger) pendant que jQuery manipule encore les mêmes nœuds DOM, vous pouvez obtenir un « tir à la corde » UI : le framework rerend et écrase les changements jQuery, tandis que jQuery modifie des éléments que le framework pense contrôler.
Règle pratique : définissez une frontière claire. Soit :
Beaucoup de code ancien repose sur des événements délégués comme :
$(document).on('click', '.btn', handler)
Le DOM natif peut faire la même chose, mais le matching et les attentes autour de this/event.target changent. Les bugs courants incluent des handlers qui se déclenchent pour le mauvais élément (à cause d'icônes/spans imbriqués) ou qui ne se déclenchent pas pour des éléments ajoutés dynamiquement parce que l'écouteur était attaché au mauvais ancêtre. En remplaçant la délégation, confirmez :
closest() est souvent nécessaire)Les effets jQuery UI et animations personnalisées pouvaient masquer ou introduire des problèmes d'accessibilité. Quand vous remplacez des fondus, slides et basculements, revérifiez :
aria-expanded sur les boutons de divulgation)prefers-reduced-motion)Détecter ces pièges tôt accélère la migration et rend votre UI plus fiable — même avant que le dernier $() ait disparu.
jQuery n'est pas « mauvais ». Il a résolu de vrais problèmes — surtout quand les navigateurs se comportaient différemment et que construire des pages interactives signifiait écrire beaucoup de code DOM répétitif. Ce qui a changé, c'est que vous n'en avez généralement plus besoin pour de nouveaux projets.
Plusieurs forces l'ont poussé du statut de choix par défaut à dépendance legacy :
Si vous maintenez un site ancien, jQuery peut rester un outil parfaitement raisonnable — surtout pour des corrections mineures, des plugins stables ou des pages qui ne justifient pas une reconstruction complète. Si vous développez de nouvelles fonctionnalités, visez d'abord le JavaScript natif et ne conservez jQuery que lorsqu'il vous fait clairement gagner du temps.
Pour poursuivre l'apprentissage utile au travail réel, consultez :
Si vous évaluez comment moderniser plus vite, pensez à des outils qui vous aident à prototyper et livrer par étapes. Koder.ai peut être utile : vous décrivez le comportement souhaité en chat, générez une UI basée sur React et un backend Go/PostgreSQL si besoin, puis exportez le code source quand vous êtes prêt à l'intégrer dans une base existante.
Si vous évaluez des outils ou des options de support, vous pouvez aussi consulter : /pricing
jQuery est une bibliothèque JavaScript qui simplifie les tâches courantes côté navigateur : sélectionner des éléments, gérer des événements, effectuer des requêtes Ajax et réaliser des effets simples (afficher/masquer, fondus, glissements). Son motif caractéristique est l'utilisation de la fonction () pour trouver des éléments puis chaîner des actions dessus.
$ est simplement une fonction raccourcie (généralement fournie par jQuery) qui recherche des éléments dans la page — similaire à document.querySelectorAll() — et retourne un objet jQuery sur lequel on peut chaîner des méthodes.
Si vous voyez $() dans du code ancien, cela signifie souvent « sélectionner quelque chose, puis en faire quelque chose ».
jQuery est devenu populaire car il rendait le comportement incohérent des navigateurs plus prévisible. Aux débuts du web, des opérations simples comme gérer des événements, parcourir le DOM ou faire de l'Ajax demandaient des contournements spécifiques à chaque navigateur.
jQuery offrait une API unique et prévisible, permettant aux équipes de livrer plus vite avec moins de surprises cross‑browser.
Principalement parce que les navigateurs et JavaScript ont rattrapé leur retard. Aujourd'hui, on peut souvent remplacer les tâches classiques de jQuery par des fonctionnalités natives :
querySelector / querySelectorAll pour la sélectionNon. Beaucoup de sites existants l'utilisent encore, et il continue de fonctionner. « Héritage » signifie surtout qu'on le trouve plus dans les vieux codebases que dans les nouveaux. La vraie question pratique est de savoir s'il vaut la peine de le garder en fonction des performances, de la maintenance et des dépendances actuelles (en particulier les plugins).
Parce qu'il est profondément intégré dans des écosystèmes anciens — surtout des thèmes et plugins. Un exemple courant est WordPress, où de nombreuses extensions supposent historiquement la présence de jQuery.
Si votre site dépend d'un plugin qui n'existe qu'en version jQuery (slider, datepicker, lightbox, validateurs), supprimer jQuery revient souvent à remplacer ce plugin, pas seulement à modifier quelques lignes de code.
Oui, dans plusieurs situations pratiques :
Dans ces cas, la stabilité et la rapidité peuvent primer sur la réduction des dépendances.
Commencez progressivement et mesurez l'impact :
La délégation d'événements est un piège fréquent. Du code jQuery comme :
$(document).on('click', '.btn', handler)
repose sur le comportement de matching et sur la valeur de this dans jQuery. En natif, il faut souvent :
Oui — les effets et réécritures du DOM peuvent casser l'accessibilité. Quand vous remplacez hide()/show() ou des fondus/diapositives, vérifiez :
aria-expandedprefers-reduced-motion)Maintenir le comportement identique, ce n'est pas que l'apparence : c'est aussi le flux d'interaction et l'accès clavier.
classList pour modifier les classesaddEventListener pour les événementsfetch + async/await pour les requêtesAinsi, les nouveaux projets ont moins souvent besoin d'une couche de compatibilité.
$.ajax() en fetch() endpoint par endpoint.Des PRs petites et des déploiements par étapes réduisent le risque de régressions.
event.target.closest('.btn') pour identifier l'élément viséTestez aussi les cas de contenu dynamique (éléments ajoutés après le chargement).