Discussion :

[Jade Emy]

Lancement de jQuery v4.0 Beta, cette nouvelle version de la bibliothèque JavaScript ne prend plus en charge les versions d'Internet Explorer antérieures à 11

La version 4.0.0 de jQuery est en préparation depuis longtemps, mais elle est maintenant prête pour une version bêta ! Elle corrige des bogues, améliore les performances et apporte quelques changements. La prise en charge d'Internet Explorer (IE) 10 et des versions antérieures a été supprimé de cette version. Cependant, selon l'équipe de jQuery, on peux s'attendre à ce que les perturbations soient minimes.

jQuery est une bibliothèque JavaScript conçue pour simplifier la traversée et la manipulation de l'arbre HTML DOM, ainsi que la gestion des événements, les animations CSS et Ajax. Il s'agit d'un logiciel open-source, libre et gratuit utilisant la licence permissive MIT. En août 2022, jQuery était utilisé par 77 % des 10 millions de sites web les plus populaires. L'analyse du web indique qu'il s'agit de la bibliothèque JavaScript la plus largement déployée, avec une marge importante, puisqu'elle est au moins trois à quatre fois plus utilisée que n'importe quelle autre bibliothèque JavaScript.

La syntaxe de jQuery est conçue pour faciliter la navigation dans un document, la sélection d'éléments DOM, la création d'animations, la gestion d'événements et le développement d'applications Ajax. jQuery permet également aux développeurs de créer des plug-ins au-dessus de la bibliothèque JavaScript. Cela permet aux développeurs de créer des abstractions pour l'interaction et l'animation de bas niveau, des effets avancés et des widgets de haut niveau pouvant être thématisés. L'approche modulaire de la bibliothèque jQuery permet de créer de puissantes pages web dynamiques et des applications web.

Pour jQuery 4.0.0 Beta, la plupart des changements sont ceux que l'équipe voulait faire depuis des années, mais qu'elle ne pouvait pas faire dans un patch ou une version mineure. Ils ont réduit le code hérité, supprimé certaines API précédemment obsolètes, supprimé certains paramètres internes aux fonctions publiques qui n'ont jamais été documentés, et abandonné la prise en charge de certains comportements "magiques" qui étaient trop compliqués. Voici quelques points forts de jQuery 4.0.0 beta.

Adieu IE<11

jQuery 4.0 abandonne la prise en charge d'Internet Explorer (IE) 10 et des versions antérieures. Certains se demandent peut-être pourquoi ils n'ont pas supprimé la prise en charge d'IE 11. Ils prévoient de supprimer le support par étapes, et la prochaine étape aura lieu dans jQuery 5.0. Pour l'instant, ils commençent par supprimer le code prenant spécifiquement en charge les versions d'IE antérieures à 11, ce qui donne une réduction de taille de -867 octets gzippés en un seul PR !

Ils ont également supprimé la prise en charge d'autres navigateurs très anciens, notamment Edge Legacy, iOS <11, Firefox <65, et Android Browser. Aucun changement ne devrait être nécessaire de côté utilisateur. Si on a besoin de supporter l'un de ces navigateurs, il suffit rester simplement avec jQuery 3.x.

API obsolètes supprimées

Ces fonctions sont obsolètes depuis plusieurs versions. Il est temps de les supprimer maintenant que la mise à jour a atteint une version majeure. Ces fonctions ont toujours été destinées à être internes ou ont maintenant des équivalents natifs dans tous les navigateurs supportés. Les fonctions supprimées sont les suivantes :

• 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

push, sort, et splice supprimé

Le prototype jQuery comporte depuis longtemps des méthodes Array qui ne se comportent pas comme les autres méthodes jQuery et qui ont toujours été destinées à un usage interne uniquement. Ces méthodes sont push, sort et splice. L'équipe a transféré l'utilisation de ces méthodes vers les fonctions Array au lieu du prototype jQuery. Par exemple, $elems.push( elem ) est devenu [].push.call( $elems, elem ). Il est mentionné ici au cas où il y aurait des plugins qui se seraient appuyés sur ces méthodes.

Ordre des événements focusin et focusout

Pendant longtemps, les navigateurs n'étaient pas d'accord sur l'ordre des événements de mise au point et de flou, qui comprennent focusin, focusout, focus, and blur. Enfin, les dernières versions de tous les navigateurs pris en charge par jQuery 4.0 ont convergé vers un ordre commun des événements. Malheureusement, il diffère de l'ordre cohérent que jQuery avait choisi il y a plusieurs années, ce qui en fait un changement radical. Au moins, tout le monde est sur la même longueur d'onde maintenant !

Dans les versions précédentes, l'ordre de jQuery pour les quatre événements était le suivant :

1. focusout
2. blur
3. focusin
4. focus

À partir de la version 4.0 de jQuery, le comportement natif n'est plus. Cela signifie que tous les navigateurs, à l'exception d'IE, suivront la spécification actuelle du W3C, à savoir :

1. blur
2. focusout
3. focus
4. focusin

Pour les curieux, la spécification du W3C définissait auparavant un ordre différent :

1. focusout
2. focusin
3. focusin
4. blur

Mais peu de gens ont pensé que c'était intuitif et la spécification a été modifiée en 2023 pour correspondre à ce que les navigateurs avaient déjà mis en œuvre. Ironiquement, le seul navigateur à avoir suivi l'ancienne spécification est Internet Explorer.

Prise en charge de FormData

jQuery.ajax a ajouté la prise en charge des données binaires, y compris FormData. Auparavant, les données binaires n'étaient pas un type de données connu et étaient converties en chaînes de caractères. Ce comportement pouvait être désactivé en désactivant la conversion des données et en traitant les données manuellement, mais ils ont décidé de le faire fonctionner automatiquement. Il s'agit techniquement d'une rupture, mais le comportement devrait être plus proche de celui attendu.

Suppression de la promotion automatique de JSONP

Auparavant, jQuery.ajax avec dataType : "json" avec un callback fourni était automatiquement converti en une requête JSONP. Aujourd'hui, la manière préférée d'interagir avec un backend inter-domaine est avec CORS, qui fonctionne dans tous les navigateurs supportés par jQuery 4.0. Cela devrait permettre d'éviter des comportements inattendus dans le cas où un développeur ne sait pas qu'un code peut être exécuté à partir d'un domaine distant avec JSONP.

La source de jQuery migre vers les modules ES

Ce fut un jour spécial lorsque la source de jQuery sur la branche main a été migrée d'AMD vers des modules ES. Les sources de jQuery ont toujours été publiées avec les versions de jQuery sur npm et GitHub, mais ne pouvaient pas être importées directement en tant que modules sans RequireJS, qui était l'outil de construction de jQuery de prédilection. Depuis, ils sont passés à Rollup pour l'empaquetage de jQuery. L'équipe éffectue également des tests sur les modules ES avant de les empaqueter.

Types de confiance et CSP

jQuery 4.0 ajoute la prise en charge des Types de confiance (Trusted Types), garantissant que le HTML enveloppé dans TrustedHTML peut être utilisé comme entrée dans les méthodes de manipulation de jQuery d'une manière qui n'enfreint pas la directive Content Security Policy require-trusted-types-for.

Par ailleurs, alors que certaines requêtes AJAX utilisaient déjà des balises <script> pour maintenir des attributs tels que crossdomain, ils ont depuis changé la plupart des requêtes de script asynchrones pour utiliser <script> afin d'éviter toute erreur CSP causée par l'utilisation de scripts en ligne. Il existe encore quelques cas où XHR est utilisé pour les requêtes de script asynchrones, comme lorsque l'option "headers" est passée (utilisez scriptAttrs à la place !), mais on utilise maintenant une balise <script> chaque fois que cela est possible.

Mise à jour

L'équipe de jQuery ne prévoit pas de problèmes de compatibilité lors de la mise à jour à partir d'une version jQuery 3.0+. Si vous n'avez pas encore mis à jour vers jQuery 3.0, consultez le Guide de mise à jour 3.5 et le Guide de mise à jour 3.0.

Le plugin jQuery Migrate vous aidera à identifier les problèmes de compatibilité dans votre code. N'hésitez pas à tester cette version bêta et à faire part des problèmes que vous rencontrez.

Si vous ne pouvez pas encore passer à la version 3.5+, Daniel Ruf a gentiment fourni des correctifs pour les versions précédentes de jQuery.

Mise à jour de slim build

Le slim build est devenu encore plus petit dans jQuery 4.0.0 avec la suppression des Deferreds et des Callbacks (maintenant moins de 20k octets gzippés !). Les Deferreds ont longtemps supporté le standard Promises A+, donc les Promises natives peuvent être utilisées à la place dans la plupart des cas et elles sont disponibles dans tous les navigateurs supportés par jQuery à l'exception d'IE11. Les Deferreds ont quelques fonctionnalités supplémentaires que les Promises natives ne supportent pas, mais la plupart de leur utilisation peut être migrée vers les méthodes Promise. Si vous avez besoin de supporter IE11, il est préférable d'utiliser la version principale ou d'ajouter un polyfill pour les promesses natives.

Téléchargement

Vous pouvez obtenir les fichiers à partir du CDN de jQuery, ou les lier directement :

https://code.jquery.com/jquery-4.0.0-beta.js

https://code.jquery.com/jquery-4.0.0-beta.min.js

Vous pouvez également télécharger cette version depuis npm :

npm install jquery@4.0.0-beta

Slim build

Parfois, vous n'avez pas besoin d'ajax, ou vous préférez utiliser l'une des nombreuses bibliothèques autonomes qui se concentrent sur les requêtes ajax. Et il est souvent plus simple d'utiliser une combinaison de CSS et de manipulation de classes pour les animations web. Enfin, tous les navigateurs supportés par jQuery (à l'exception d'IE11) prennent désormais en charge les promesses natives, de sorte que les Deferreds et les Callbacks ne sont plus nécessaires dans la plupart des cas. En plus de la version normale de jQuery qui inclut tout, une version "slim" qui exclut ces modules a été publiée. La taille de jQuery est très rarement un problème de performance de charge de nos jours, mais la version "slim" est environ 8k octets gzippés plus petite que la version normale. Ces fichiers sont également disponibles dans le paquet npm et sur le CDN :

https://code.jquery.com/jquery-4.0.0-beta.slim.js

https://code.jquery.com/jquery-4.0.0-beta.slim.min.js

Ces mises à jour sont déjà disponibles en tant que versions actuelles sur npm et Bower. Des informations sur toutes les façons d'obtenir jQuery sont disponibles à l'adresse https://jquery.com/download/. Les CDN publics reçoivent leurs copies aujourd'hui, veuillez leur laisser quelques jours pour poster les fichiers. Si vous souhaitez démarrer rapidement, utilisez les fichiers sur le CDN de l'équipejQuery jusqu'à ce qu'ils aient une chance de se mettre à jour.

Nous publierons un guide de mise à jour complet avant la version finale, afin de présenter le code supprimé et la manière de migrer. Le plugin jQuery Migrate sera également prêt à vous aider. Pour l'instant, nous vous invitons à tester la version bêta et à nous faire savoir si vous rencontrez des problèmes.

Source : Annonce de jQuery v4.0 Beta

Et vous ?

Quel est votre avis sur cette mise à jour ?

Voir aussi :

L'impact de la suppression de jQuery sur les performances Web : l'expérience de GOV.UK, site Web d'information du secteur public du Royaume-Uni

jQuery 3.6.0 est disponible, mais la bibliothèque JavaScript est-elle encore beaucoup utilisée en 2021 ?

État de JavaScript 2022 : React reste le framework front-end dominant mais est en perte de vitesse côté satisfaction, JQuery est la troisième bibliothèque la plus utilisée

[Leruas]

Même IE 11, quel intérêt de le supporter encore alors qu'il est abandonné depuis 3 ans ?

Ces fonctions ont toujours été destinées à être internes ou ont maintenant des équivalents natifs dans tous les navigateurs supportés

Oui c'est le cas de presque tout ce que fait jQuery, donc quel intérêt de supprimer certaines API et pas tout ?

[Padget]

Je trouve que c'est une bonne idée de conserver et de développer jquery. Cela permet d'entretenir un patrimoine logiciel, jquery étant un pionnier sur les technologies web. Et de plus on conserve un état de l'art en le maintenant.

[archqt]

Je ne suis pas expert web, mais il me semblait que javascript+html5+cc contenait tous les éléments de jquery avec un code aussi court, mais en plus rapide car directement dans le langage.

[dragonofmercy]

Je ne suis pas expert web, mais il me semblait que javascript+html5+cc contenait tous les éléments de jquery avec un code aussi court, mais en plus rapide car directement dans le langage.

En théorie, cela peut sembler vrai, mais dans la pratique, ce n'est pas toujours le cas. Par exemple, prenons le cas de Bootstrap, qui a abandonné jQuery pour le natif. Le résultat est que leur bibliothèque JavaScript est désormais deux fois plus volumineuse que l'ancienne qui contenait à la fois leur propre code et jQuery.

De plus, il est important de noter qu'il existe encore de nombreuses bibliothèques qui utilisent jQuery. Par conséquent, tôt ou tard, vous devrez probablement l'ajouter à votre site si vous utilisez ces bibliothèques.

En ce qui concerne les performances, dans la plupart des cas (environ 98%), les différences ne sont pas perceptibles. Cependant, il est probable que vous remarquerez des différences dans les applications qui utilisent de très grandes bibliothèques JavaScript.

[irrmichael]

Je suis content que jquery soit mis à jour. Je ne vois pas encore comment je pourrais m'en passer dans mes projets web futurs.

[Stéphane le calme]

À l'occasion de ses 20 ans, la bibliothèque Javascript jQuery passe en version 4.0.0 :
face aux frameworks modernes, faut-il maintenir, migrer ou abandonner un socle historique du front-end ?

Le web de 2026 n’est plus celui qui a vu naître jQuery. Les problématiques ont changé, les outils aussi. Pourtant, ignorer jQuery serait une erreur stratégique pour de nombreux décideurs techniques, tant il reste central dans l’écosystème réel des sites en production. En mettant fin au support des navigateurs obsolètes et en nettoyant une API chargée d’histoire, jQuery 4.0.0 assume pleinement son statut de bibliothèque de transition. Ni framework moderne, ni relique inutile, elle occupe une zone grise que beaucoup d’équipes connaissent bien : celle du pragmatisme technique.

En janvier 2026, la bibliothèque jQuery a célébré ses 20 ans en annonçant la sortie de la version 4.0.0 – sa première mise à niveau majeure en presque dix ans. Historiquement omniprésent dans le développement web front-end, jQuery s’est imposé dès la fin des années 2000 comme un outil incontournable pour « écrire moins, faire plus » en JavaScript. Il a grandement simplifié la manipulation du DOM HTML, la gestion des événements, les requêtes AJAX et les animations, à une époque où ces tâches étaient complexes et hétérogènes selon les navigateurs.

Au fil des années, un large écosystème de plugins s’est développé autour de jQuery, et de nombreux développeurs ont fait leurs premières armes en JavaScript à travers cette API familière. Encore aujourd’hui, jQuery reste la bibliothèque JavaScript la plus déployée sur le web : on estime qu’il est utilisé par environ 77 % des 10 millions de sites les plus visités en 2022 et par plus de 70 % de l’ensemble des sites web début 2026, ce qui le place loin devant toute autre librairie JavaScript en termes de présence en production. Cette longévité exceptionnelle interroge son rôle à l’ère des frameworks modernes comme React, Vue ou Svelte.

Historique de jQuery et cas d’usage

jQuery a été créé par John Resig et dévoilé en 2006 lors du BarCamp NYC, avec pour ambition de simplifier le code JavaScript côté client. À une époque où chaque navigateur implémentait le DOM et les événements à sa manière, jQuery a fourni une abstraction unifiée qui a démocratisé le développement JavaScript. La bibliothèque a rendu les manipulations d’éléments HTML plus aisées (grâce à sa syntaxe de sélecteurs inspirée de CSS), a normalisé des comportements d’événements qui différaient entre Internet Explorer, Firefox ou Safari, et a introduit des utilitaires pour les effets visuels et les requêtes asynchrones (AJAX) simples à utiliser. Comme le résume un article, « jQuery a rendu AJAX accessible, a normalisé la gestion des événements et offert une API élégante pour le DOM à une époque de fragmentation des navigateurs ». Son slogan officieux « Write Less, Do More » traduisait bien cette promesse.

Le succès de jQuery a été fulgurant. Durant la décennie 2010, il est devenu quasiment synonyme de JavaScript pour de nombreux développeurs front-end. Microsoft et Nokia l’ont même intégré nativement à leurs plateformes de développement web à l’époque. Des bibliothèques complémentaires comme jQuery UI (composants d’interface) ou jQuery Mobile ont vu le jour pour exploiter son cœur, et des milliers de plugins communautaires ont étendu ses fonctionnalités (carrousels, datepickers, graphiques, etc.). Les cas d’usages typiques de jQuery allaient du simple script ajoutant une animation sur un bouton, jusqu’à des applications web complètes construites autour de son modèle d’interaction DOM.

Malgré l’essor récent de frameworks front-end alternatifs, l’empreinte de jQuery demeure colossale sur le web actuel. S'il affiche un déclin progressif, jQuery est encore présent sur plus de 70 % des sites au début de 2026. Ce maintien s’explique par l’héritage de nombreux projets et CMS plus anciens (par exemple WordPress l’inclut d’office), tandis que pour les applications web développées ces dernières années, on lui préfère largement des frameworks plus modernes. En somme, jQuery fait aujourd’hui figure de « vétéran » du front-end : sa popularité auprès des nouveaux projets a diminué, mais il reste un composant sous-jacent d’innombrables sites en production, bénéficiant d’une base d’utilisateurs immense et d’une communauté toujours active.

Nouveautés de jQuery 4.0.0

Lancée officiellement en janvier 2026, jQuery 4.0.0 est la première version majeure de la bibliothèque depuis près de dix ans. Après une longue phase de développement et plusieurs préversions bêta, cette mise à jour apporte de nombreuses améliorations et modernisations, accompagnées de changements pouvant casser la compatibilité ascendante (breaking changes). Les mainteneurs ont profité de ce saut de version pour nettoyer le code historique et abandonner certains archaïsmes, tout en veillant à ce que la migration soit la plus fluide possible – la plupart des utilisateurs devraient pouvoir passer à jQuery 4 avec très peu de modifications de code, selon l’annonce officielle.

Voici les principaux apports et changements de jQuery 4.0.0 :

Fin de support des navigateurs anciens

Première évolution notable, jQuery 4 abandonne la prise en charge des navigateurs web obsolètes, en particulier Internet Explorer 10 et les versions antérieures. Concrètement, le code spécifique qui permettait à jQuery de fonctionner avec IE 6/7/8/9/10 a été supprimé, ce qui allège la bibliothèque et permet d’exploiter davantage les API modernes des navigateurs récents. À titre transitoire, IE 11 reste encore supporté dans la v4, mais son tour viendra – l’équipe a annoncé que jQuery 5.x éliminerait à son tour le support d’IE 11. Outre Internet Explorer, d’autres navigateurs vieillissants sortent du périmètre : la version héritée d’Edge (Edge Legacy), les anciens Safari/iOS antérieurs aux trois dernières versions majeures, les Firefox antérieurs aux deux dernières versions (hors édition ESR), ainsi qu’Android Browser (le vieux moteur par défaut des Android 4) ne sont plus garantis compatibles. Pour les applications qui auraient absolument besoin de fonctionner sur ces environnements désuets, la consigne est claire : rester sur jQuery 3.x sans migrer vers la 4.

Modernisation du code et sécurité renforcée

jQuery 4 se modernise également sous le capot. Le code source de la bibliothèque a été entièrement migré du format AMD vers les modules ES (ECMAScript modules), une évolution interne qui la rend plus facilement intégrable aux outils de construction modernes (tels Webpack, Rollup) et aux workflows basés sur import/export en JavaScript ES6. Désormais, on peut importer jQuery en tant que module, ou le charger via une balise <script type="module"> dans les navigateurs récents, ce qui aligne la bibliothèque avec les pratiques de développement actuelles.

Par ailleurs, d’importants efforts ont été faits sur la sécurisation des manipulations DOM. jQuery 4 introduit le support de l’API Trusted Types, qui permet de mieux se conformer aux politiques de sécurité de contenu (Content Security Policy) des pages web. En pratique, cela signifie que si un développeur fournit à jQuery du code HTML marqué explicitement comme sûr (via un objet TrustedHTML), la bibliothèque l’acceptera pour l’injection dans le DOM sans déclencher d’alerte CSP, là où auparavant ce type d’opération pouvait être bloqué par les navigateurs pour prévenir les failles XSS.

Dans le même esprit, le mécanisme de chargement de scripts externes via AJAX a été ajusté pour éviter les violations de CSP : jQuery utilise dorénavant des balises <script> pour insérer les scripts distants dans la page, au lieu de techniques d’injection de code potentiellement considérées comme du script inline non sûr. Hormis quelques cas particuliers (par ex. si des en-têtes HTTP personnalisés sont requis, où un XHR reste utilisé), les chargements de scripts se feront via des balises, ce qui contourne les restrictions CSP sur l’exécution de code dynamique.

Suppression des API obsolètes

L’équipe de jQuery a profité de ce passage en version 4 pour effectuer un grand ménage dans les fonctionnalités anciennes et redondantes. Au fil des versions 2.x et 3.x, plusieurs fonctions de l’API avaient été signalées comme dépréciées (deprecated) en vue d’une suppression future – jQuery 4 acte précisément cette suppression. Ainsi, toute une série de méthodes utilitaires globales disparaissent au profit des équivalents standards du JavaScript moderne : par exemple jQuery.isArray, jQuery.trim, jQuery.parseJSON, jQuery.isFunction ou jQuery.type ont été retirées, car il existe désormais dans tous les navigateurs supportés des alternatives natives pour ces fonctionnalités (Array.isArray() pour tester un tableau, String.prototype.trim() pour enlever les espaces, JSON.parse() pour parser du JSON, typeof ou instanceof pour tester le type, etc.). Tout code s’appuyant sur ces anciennes fonctions devra donc être adapté en conséquence.

De même, jQuery 4 retire certaines propriétés et méthodes internes jugées inutiles ou « magiques ». Par exemple, les méthodes non documentées qui figuraient sur l’objet prototype de jQuery – comme $._data, ou encore les méthodes de tableau héritées (push, sort, splice) – ont été purgées pour éviter toute confusion. Il était déconseillé de les utiliser, mais dans la pratique certains développeurs détournaient $(éléments).push(obj) pour manipuler des collections jQuery comme de simples tableaux ; ce genre de code ne fonctionnera plus et doit être réécrit en utilisant les méthodes natives. L’effet positif de ce nettoyage est un allègement de la taille de la bibliothèque, d’environ 3 kilooctets une fois minifiée et compressée en gzip – un gain modeste mais bienvenu, rendu possible notamment grâce à l’abandon du support des très vieux navigateurs.

Compatibilité et migration : quel impact pour vos projets ?

Qui dit version majeure dit risque de ruptures de compatibilité. Dans le cas de jQuery 4.0.0, nous l’avons vu, il y a effectivement plusieurs changements notables, mais la bonne nouvelle est que la migration depuis jQuery 3.x devrait être relativement aisée dans la plupart des cas. L’équipe jQuery indique avoir fait en sorte que la majorité des utilisateurs puissent effectuer la mise à jour avec « des changements minimes dans leur code ». Les principales incompatibilités proviennent de la suppression de vieux code et de comportements atypiques, que les développeurs avertis avaient souvent déjà évité via les recommandations des versions précédentes. En outre, ce passage en v4 était planifié de longue date : plusieurs des fonctionnalités retirées étaient signalées comme dépréciées depuis des années. En interne, le passage à la version 4 a permis de réaliser enfin ces nettoyages qui étaient impossibles en version mineure

Pour accompagner les développeurs dans cette transition, l’équipe fournit un outil précieux : le plugin jQuery Migrate 4.0. Il s’agit d’un fichier JavaScript additionnel à inclure temporairement dans vos pages, qui va détecter automatiquement et signaler dans la console tout usage de fonctionnalité obsolète ou cassée sous jQuery 4. Mieux, dans sa version de production minimifiée, Migrate 4 peut rétablir en interne certains comportements retirés, de façon à ce que votre application continue de fonctionner pendant la phase de migration sans erreur bloquante.

jQuery face aux frameworks modernes : quelle pertinence en 2026 ?

Avec l’essor des frameworks front-end ces dix dernières années, le paysage du développement web s’est profondément transformé. Des bibliothèques et frameworks tels qu’AngularJS/Angular, React (introduit par Facebook en 2013), Vue.js (2014) ou plus récemment Svelte (2019) ont popularisé une approche différente : plutôt que de manipuler directement le DOM de manière impérative, on structure l’application en composant des éléments d’interface autonomes, reliés à un état applicatif central, et on laisse le framework se charger d’appliquer efficacement les mises à jour nécessaires à l’écran.

Cela apporte une meilleure organisation du code, une séparation des préoccupations (logique vs présentation) plus nette et souvent des gains de performance grâce à des techniques comme le Virtual DOM ou le reactive computing. Dans ce contexte architectural moderne, jQuery n’est plus le choix naturel pour développer une application web dynamique de grande envergure. Son modèle (sélectionner des éléments du DOM et leur attacher des handlers ou des modifications directement) convient très bien pour des enrichissements ponctuels d’une page web, mais montre vite ses limites en termes de maintenabilité dès qu’il s’agit de gérer une interface utilisateur complexe avec de multiples états synchronisés.

Il est donc devenu rarissime en 2026 de démarrer un nouveau projet web ambitieux en s’appuyant sur jQuery comme base principale : la tendance générale est d’opter pour un des frameworks modernes sus-cités, qui offrent une structure robuste dès le départ. D’ailleurs, la plupart des templates ou boilerplates proposés pour les applications web aujourd’hui intègrent un framework (ou au minimum une bibliothèque comme Preact, Alpine.js, Stimulus, etc.), là où dans les années 2010 on incluait quasi systématiquement jQuery par défaut.

Le statut de jQuery a glissé de « bibliothèque universelle pour faire du JS sur le web » vers celui d’un outil spécialisé, adapté à certaines situations bien précises. Par exemple, pour un site essentiellement statique ayant juste besoin de quelques interactions (un diaporama, un menu déroulant, un formulaire amélioré), ajouter jQuery peut rester une solution plus simple et rapide que d’embarquer la machinerie d’un framework complet. Son API reste plus accessible pour un débutant qu’un écosystème comme React qui impose de maîtriser de nombreux concepts (JSX, état local vs global, build toolchain, etc.). Comme le souligne un article récent, la simplicité et l’universalité de jQuery en font encore un « outil inestimable » pour les développeurs de tous niveaux, grâce à sa syntaxe concise et sa multitude de plugins disponibles.

Cependant, s’il est facile et pertinent de recourir à jQuery dans un contexte limité, ce choix devient plus discutable à l’échelle d’applications web complètes. Les frameworks modernes apportent des réponses natives à des problématiques que jQuery laisse entièrement à la charge du développeur : structuration modulaire du code, rendu conditionnel performant, synchronisation de la vue avec des données, routage côté client, tests unitaires des composants, etc. Cela explique qu’en termes de projets en cours de développement actif, jQuery a cédé le terrain – non pas parce qu’il aurait « cessé de fonctionner », mais parce que le paradigme de développement web a changé d’orientation.

Beaucoup de fonctionnalités qui justifiaient autrefois l’usage de jQuery font désormais partie du socle standard du web : par exemple, la sélection d’éléments peut se faire via document.querySelectorAll sans bibliothèque externe, la modification de classes CSS via element.classList est tout aussi simple que $(element).addClass(), les appels réseau AJAX se font désormais avec l’API fetch() ou XMLHttpRequest, et même pour les animations, les CSS modernes et l’API Web Animations permettent de se passer de jQuery. En d’autres termes, les navigateurs ont rattrapé leur retard et offrent nativement presque tout ce que jQuery apportait pour combler leurs lacunes. Dans ce contexte, continuer à utiliser jQuery par habitude peut ajouter une surcouche inutile (poids du fichier, dépendance supplémentaire) si l’on n’en exploite pas spécifiquement les atouts.

Conclusion

En célébrant deux décennies d’existence avec la version 4.0.0, jQuery confirme sa volonté de s’adapter à l’écosystème web moderne tout en restant fidèle à sa mission originelle. Cette mise à jour majeure apporte un souffle de modernisation à la bibliothèque : le nettoyage des vieilles API et du code dédié aux navigateurs d’un autre âge, l’adoption des modules ES et des mécanismes de sécurité modernes, tout cela permet à jQuery de continuer à fonctionner de manière optimale sur les applications web d’aujourd’hui et de demain. Pour les innombrables projets qui en dépendent, c’est un signal rassurant : jQuery n’est pas abandonné, il évolue pour rester un choix viable en 2026 et au-delà.

Bien sûr, cette évolution s’accompagne d’une prise de recul lucide sur la place de jQuery face aux autres technologies. La bibliothèque n’est plus le pilier central du développement front-end qu’elle fut autrefois, et la plupart des nouvelles applications web préfèrent s’appuyer sur des frameworks plus récents et structurés. Mais jQuery conserve un rôle crucial en tant que technologie de maintenance et d’interopérabilité : il continue de faire tourner discrètement une majorité de sites web, et ce faisant, il démontre qu’une innovation d’hier peut perdurer si elle sait se renouveler à la marge et rester fiable.

En fin de compte, le héritage de jQuery dans le web moderne est double : d’un côté, il a inspiré de nombreux concepts des frameworks actuels, de l’autre il assure la continuité de fonctionnement de très nombreux systèmes existants. La sortie de jQuery 4.0.0 s’inscrit dans cette continuité, en offrant aux développeurs un jQuery plus propre, plus sûr et mieux intégré qu’hier – tout en les laissant libres de choisir la voie à suivre pour leurs projets futurs, entre prolonger ce socle historique ou embrasser de nouvelles approches.

Sources : annonce jQuery, jQuery script

Et vous ?

La sortie de jQuery 4.0.0 impose-t-elle réellement une mise à jour, ou confirme-t-elle au contraire que jQuery est désormais un outil de maintenance plus qu’un choix stratégique ?

Mettre à jour vers jQuery 4.0.0 est-il un investissement rationnel pour les équipes techniques, ou un simple moyen de repousser une refonte front-end devenue inévitable ?

Le nettoyage des API et l’abandon des anciens navigateurs marquent-ils une modernisation bienvenue, ou la reconnaissance implicite que jQuery n’a plus vocation à accompagner tous les usages du web ?

Dans un écosystème où les API natives couvrent désormais la majorité des besoins historiques de jQuery, quel est encore le véritable différenciateur de la bibliothèque ?

Faut-il considérer jQuery 4.0.0 comme une solution de transition pour prolonger la durée de vie des applications existantes, ou comme un signal indiquant qu’il est temps de sortir définitivement du modèle jQuery ?