Discussion :

[Michael Guilloux]

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

L'équipe jQuery vient d'annoncer une nouvelle version de la célèbre bibliothèque JavaScript : jQuery 3.6.0. Dans la version précédente, le changement majeur était un correctif de sécurité pour le préfiltre HTML. Dans cette nouvelle version, il n'y a pas de correctif de sécurité, mais quelques corrections de bogues et améliorations.

Dans les versions précédentes, lorsqu'une requête JSONP répondait avec une erreur, la réponse était toujours un script exécutable. Ce comportement par défaut a été corrigé dans jQuery 3.6.0. Les autres bogues qui ont été corrigés concernent la redirection du focus vers un autre élément dans un gestionnaire de focus, la récupération des dimensions sur les lignes de tableau dans Firefox et un plantage dans Chrome lorsqu'un événement focusout était déclenché sur un élément supprimé. On notera également plusieurs améliorations à certains tests entre autres.

Vous l'avez certainement deviné, la version jQuery 4.0 annoncée depuis quelques années déjà va devoir encore attendre. Cette version sera une refonte de la bibliothèque JavaScript. En effet, l'API de base de jQuery consiste à sélectionner un élément, puis à faire quelque chose avec ce qui a été sélectionné. Sizzle, le moteur de sélection dans jQuery, gère la première partie. C’est un petit moteur rapide et efficace qui a ouvert la voie à des API de sélecteur natif telles que querySelectorAll ainsi qu’à des sélecteurs JavaScript et CSS natifs supplémentaires. Mais maintenant, beaucoup de ces sélecteurs sont intégrés dans les navigateurs modernes. L'équipe jQuery estime donc qu'il est presque temps de dire au revoir à Sizzle, ce qu'elle prévoit de faire dans la version 4.0. L'équipe jQuery assure y travailler, mais d'ici là, elle continuera à prendre en charge la branche 3.x et à résoudre des problèmes importants.

La bibliothèque JavaScript est-elle encore utilisée aujourd'hui ?

Créé pour simplifier l'écriture de JavaScript et HTML, jQuery est arrivé au bon moment en 2006, avec la complexification croissante des interfaces Web. Cela lui a permis de séduire en masse les développeurs Web et d'avoir le statut d'élément fondamental dans les formations aux technologies du Web.

jQuery était il y a peu la bibliothèque JS la plus utilisée au monde et bon nombre de frameworks l'utilisaient pour fonctionner. Mais avec l'émergence de nouvelles technologies (bibliothèques et frameworks) et la modernisation des navigateurs, le caractère incontournable, voire la pertinence, de jQuery ne fait plus l'unanimité. Les problèmes qui autrefois nécessitaient jQuery sont maintenant en train d'être résolus par les navigateurs et le standard EcmaScript en évolution. Certains développeurs ont donc commencé à prendre de la distance vis-à-vis de la bibliothèque JavaScript. C'est le cas par exemple de l'équipe Bootstrap qui abandonne jQuery pour du pur JavaScript dans la version 5.0 du framework HTML, CSS et JavaScript. Le principal argument avancé pour justifier la suppression de jQuery dans Bootstrap v5 est que maintenant que plus de 95 % des fonctionnalités de jQuery sont désormais natives dans les navigateurs (les 5 % restants étant sans doute des bizarreries excessivement rétrocompatibles qui méritent d'être ignorées), donc ajouter une dépendance JS serait "stupide" ou un gaspillage de bande passante.

Dans la communauté des développeurs, les avis divergent quant à ce changement. Ceux qui l'ont bien accueilli reconnaissent que jQuery est l’une des bibliothèques les plus importantes de l’histoire JavaScript et a permis de créer de véritables applications Web. Ils estiment cependant que depuis lors, les différences entre les navigateurs se sont considérablement réduites et nous avons appris à créer des applications maintenables et évolutives de manière plus déclarative, grâce à des frameworks comme React, Angular et autres. Du coup, jQuery ne serait plus d'une grande utilité.

La suppression du moteur de sélection de jQuery parce qu'il existe maintenant des sélecteurs natifs dans les navigateurs modernes tend à donner raison à ceux qui pensent que jQuery est de moins en moins pertinent. D'autres estiment malgré tout que la bibliothèque JS est loin d'être obsolète, car les techniques jQuery ne sont pas aussi ergonomiques à mettre en œuvre sans utiliser jQuery. Pour ces derniers, ça reste donc un outil très productif qui offre des solutions simples à de nombreux problèmes. Mais jQuery est-il toujours assez populaire en 2021 ? Si oui, a-t-il encore longue vie ?

Source : Annonce de la sortie de jQuery 3.6.0

Et vous ?

Utilisez-vous jQuery en 2021 ? Pourquoi ?
jQuery a-t-il encore longue vie ?

Voir aussi :

La première version alpha de Bootstrap 5 est disponible avec des formulaires mis à jour et les propriétés CSS personnalisées, mais sans le support d'Internet Explorer et jQuery
La version 5.0 de Bootstrap supprimera le support d'Internet Explorer 11, cela fait suite à l'annonce de supprimer jQuery pour du pur JavaScript
jQuery 3.4.0 est disponible, la bibliothèque JavaScript est-elle toujours aussi utile et incontournable comme à ses débuts ?

[bilbop]

JQuery est encore très utilisé et pour longtemps.
Ce n'est pas un framework front.
D’ailleurs pour moi rien ne vaut les applications ou la logique est laissée côté back avec
un front-end le plus léger possible.

Les sélecteurs DOM en JavaScript purs sont simplement dégueulasses.
En JQuery c'est court, bref et lisible.
Les Ajax en JQuery c'est toujours aussi efficace et léger.
En JQuery il n' y'a pas de magie, c'est juste une lib qui facilite les sélections/manipulations du DOM.
C'est simple à comprendre, apprendre et à utiliser.
Cela supporte les plugins et les extensions.
C'est peut-être ça le problème, trop simple pour l'égo...
Ce n'est pas prêt de mourir.
Bootstrap a fait le choix de s'en passer, très bien cela a fait le buzz.

Pourquoi Jquery ne fait pas plus de "mise à jour" ?
Tout simplement car le produit répond déjà depuis des années aux besoins.
JQuery c'est du OldSchool, il n' a pas besoin de paillettes, ni de marketing pour être toujours aussi efficace et utilisé.

Je ne comprends pas tout, mais c'est drôle de voir comment on court vers des choses toujours plus complexes.
Avec peu de moyens, un peu de PHP, un peu de Mysql et un peu de JQuery un total débutant en dev peut rapidement monter des applications intéressantes en partant de zéro.
Et pas seulement en dev web, PHP peut être un excellent langage script.
La courbe d'apprentissage est très douce et on peut rapidement faire des applications à lourdes charges.
Je pense que ça dérange... c'est moins vendeur...
Ce n'est pas le cas d'autres langages plus à la mode.
Parfois Ils peuvent être en apparence plus facile à apprendre, mais pas à déployer ni à scaler.

La question que je me pose, quel techno on va essayer de dénigrer demain ?

PS : Les navigateurs deviennent de plus en plus complexes. Développer des navigateurs "libres" est devenu mission impossible. Ce n'est pas innocent. C'est donc peu être pas plus mal qu'une lib comme Jquery fasse encore interface en se basant sur des appels javascript plus basiques. On est moins dépendant de la marche forcée des navigateurs à toujours implémenter (ou abandonner) des fonctionnalités.

[CinePhil]

Je ne connais que JQuery et ça m'a facilité la vie bien des fois à la place de la syntaxe parfois complexe de Javascript (que j'utilise quand même relativement peu), notamment pour l'Ajax.

J'ai découvert Bootstrap assez récemment et c'est effectivement puissant. Bootstrap dit que 95% de JQuery est réalisable maintenant sans JQuery ? Si Bootstrap est capable de faire de l'Ajax aussi facilement que JQuery, faudra que je m'y intéresse de plus près.

[Lcf.vs]

Perso, je ne l'ai utilisé, à une époque, que dans un projet d'entreprise où j'étais employé, car je n'avais pas le choix, il était déjà là et je n'étais pas autorisé à le remplacer...

Je préfère grandement ma propre bibliothèque, stabilisée depuis bien longtemps : https://github.com/Lcfvs/anticore

• Beaucoup plus légère (4Ko)
• 99% du code d'un projet écrit avec ne contient que du natif
• Pas de requêtes AJAX, ni de SSE à écrire
• Flux unique d'écoute de noeuds sur lesquels on souhaite faire quelque chose
• Pousse au single responsability
• ...

[gregory13]

Les sélecteurs DOM en JavaScript purs sont simplement dégueulasses.
En JQuery c'est court, bref et lisible.
Les Ajax en JQuery c'est toujours aussi efficace et léger.
...
Bootstrap a fait le choix de s'en passer, perso j'y vois du marketing et cela a fait le buzz.

Cela doit faire pas mal de temps que tu n'as plus codé en JS sans librairie pour dire ça... Les manipulations DOM par exemple, c'est aussi simple aujourd'hui qu'en jQuery très honnêtement. Pour faire de l'ajax, on a fetch en JS qui fait largement l'affaire maintenant, avec un polyfill disponible pour être compatible partout.

Aujourd'hui jQuery c'est de plus en plus dépassé et c'est un fait, je m'en sers toujours dans certains projets donc je ne crache pas dessus ça a réellement simplifié l'utilisation du JS pendant très longtemps, mais désormais on peut faire aussi facilement en JS tout ce qu'on peut faire en jQuery. Donc c'est une librairie qui reste lourde et qui n'apporte plus grand chose aujourd'hui.

Pour les projets comme Bootstrap c'est très bien de s'en passer et d'éviter au maximum les dépendances, c'est valable pour n'importe quel projet. Je prends l'exemple d'un site vitrine tout simple, auparavant il fallait nécessairement jQuery pour faire un simple modal ou rendre responsive la navbar, c'est quelque chose de très lourd pour pas grand chose. L'utilisation de Bootstrap n'impose plus cette librairie et c'est très bien, rien n'empêche de continuer à utiliser jQuery dans le futur si voulu !

Donc je pense que ce n'est plus nécessaire d'utiliser jQuery, continuer à l'utiliser c'est avoir la flemme de se mettre à jour avec les dernières versions ECMAScript tout simplement

Cependant la où on reste d'accord c'est que jQuery est pratique car compatible avec tous les grands navigateurs et même les anciens. Mais il est très facile aujourd'hui de compiler son code JS afin d'y ajouter les polyfills nécessaires automatiquement aussi.

[goldbergg]

Si Bootstrap est capable de faire de l'Ajax aussi facilement que JQuery, faudra que je m'y intéresse de plus près.

Boostrap c'est une lib orienté UI don le but est principalement de faire du responsive, c'est pas fait pour faire de l'AJAX.

Aujourd'hui il existe fetch qui permet de facilement faire toute sorte de requête avec une écriture très simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
fetch('MON_URI').then((res) => {
 
});

ou dans un code async

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var res = await fetch('MON_URI');

https://developer.mozilla.org/en-US/...PI/Using_Fetch

C'est 100% vanilla, aucune lib a télécharger et ça fonctionne très bien.

Bref, si il y a 10 ans JQuery était pratique car il simplifié ou comblé certaines problématique de JavaScript.
Aujourd'hui c'est l'histoire ancienne, le langage a évolué et l'intérêt de JQuery c'est amoindrie.

Et le gros problème de JQuery, qui a toujours été là, c'est que ça insite a faire du code dégueu et non optimisé ou même celui qui l'a écrit ne comprend au final pas grand chose a ce qui se passe derrière.

J'ai eu l'occasion de faire pas mal de re factoring de code JQuery chopé sur notamment sur Codepen, une fois réécrie, j'ai une code pas forcement plus gros, parfois même plus light, mais dans tous les cas j'ai un code plus lisible et au performance décuplé.
JQuery C'est une lib ou on se retrouve très rapidement a faire des boucle dans des boucle dans des boucle, etc... sans même sans rendre compte.

[Invité]

Il faut bien se rendre compte que jQuery a été conçu à une époque ou chaque navigateur faisait sa petite sauce et que c'était un bordel sans nom de développer un site qui fonctionne sur tous les navigateurs. Ça a également été incroyablement utile lorsque l'AJAX est apparu, simplifiant tout le bordel et à nouveau aidant à la compatibilité entre navigateurs. Pour couronner le tout, beaucoup de fonctions d'aides pour le côté JS qui était un bordel sans nom à cette époque et, encore une fois, non standardisé entre les navigateurs, ont simplifié la vie de tous les devs.

Depuis, et heureusement, les navigateurs ont largement harmonisés leurs APIs et même si Google fait des siennes en implémentant des trucs non standards dans son coin (forçant la main des autres mais c'est un autre sujet) au moins les bases sont standardisées depuis pas mal d'années. Tout ce qui est sélecteur CSS natif, qui ressemblent furieusement à la syntaxe de jQuery, ainsi que l'API fetch, fonctionnent très bien. Le JS s'est également amélioré considérablement.

Du coup il faut bien se rendre compte que jQuery a rempli sa mission parfaitement, je pense que ça a été un facteur déterminant sur le chemin qui à mené à aujourd'hui et aux standards actuels, mais qu'il faut reconnaître que ce n'est plus très utile de nos jours. Alors certes les devs qui utilisent jQuery depuis 15 ans vont devoir se mettre à jour mais ca fait parti du job non ?

[bilbop]

J'entends vos arguments mais je pense que vous n'avez pas eu le plaisir d'utiliser JQuery depuis longtemps.

Du coup il faut bien se rendre compte que jQuery a rempli sa mission parfaitement, je pense que ça a été un facteur déterminant sur le chemin qui à mené à aujourd'hui et aux standards actuels, mais qu'il faut reconnaître que ce n'est plus très utile de nos jours. Alors certes les devs qui utilisent jQuery depuis 15 ans vont devoir se mettre à jour mais ca fait parti du job non ?

C'est assez drôle finalement.
JQuery continue de remplir sa mission et parfaitement.
Si JQuery était si inutile, il ne serait pas maintenu à jour.
Oui JQuery était là il y longtemps, et la majorité du code utilisant JQuery est toujours fonctionnel et efficace malgré les années.
JQuery pèse 89,5 ko et est mis en cache, la lourdeur n'est pas un argument.

C'est typiquement ce qui me fait sourire :

vont devoir se mettre à jour mais ca fait parti du job non ?

Par rapport à quoi à qui ? Qui décide de ce qui est obsolète ou non ?
Qui décide si je dois me mettre à jour ou non ?
Qui peut juger si je suis à jour ou non ?
Qui décide de la mort de ruby, perl, php cobol, framewokX ou libX ?
Personne. Tout simplement personne.
Tant qu'il y 'aura des développeurs qui utilisent des stacks et qui
produisent des applications fonctionnelles il n'y a aucun intérêt à changer.

Ce ne sont que des outils pour accomplir un travail.

Je suis très à jour, comme JQuery l'est encore aujourd’hui en proposant cette mise à jour.
Par exemple, je n'aime pas les arrow function, je trouve que l'async produit du code illisible. Je trouve que le code produit en JS même avec les frameworks récents est difficile à lire et comprendre.
Je trouve que les npm, composer et autres package managers sont dangereux car ils masquent la lourdeurs des dépendances.
Ils obligent par exemple à charger et stocker de gros package qu'on va utiliser à 2%.

Donc non je ne vais pas "devoir me maintenir à jour", je refuse simplement de faire comme soit disant "tout le monde".
Car cela ne me convient pas, et l'aspect "marche forcée" ne me plaît guère plus...
Je me maintiens à jour, je maintiens à jour les applications.
Je le fais juste différemment, mais ce n'est ni moins bien, ni inutile.
Nous sommes nombreux à ne pas suivre la mouvance, ce n'est pas pour rien que les recrutement sont de plus en plus difficiles.
On m'a dit fais du ruby et ruby on rail, j'ai fais du python.
On m'a dit si tu veux bosser apprends Java, j'ai perfectionné mon python.
On m'a dit fais du python et du nodejs (Django, Flask ...), je suis revenu à PHP.
On m'a dit fais du postresql et du mongodb, je suis revenu à Mysql.
On m'a dit le JS c'est de la ***, maintenant c'est le langage soit disant le plus utilisé. Ce sont les mêmes qui crachaient dessus il y'a quelques années.

Je n'écoutes plus, ce genre de chose.

[honoré_princesse]

En sortie d'études il y a un peu de moins de 10 ans, j'étais comme tous les jeunes, toujours un onglet "you don't need jquery" ouvert à rechercher une méthode alternative car plus léger, plus performant, plus moderne ...
L’expérience du monde professionnel m'a montré qu'encore maintenant, des incompatibilités subsistent, qu'encore maintenant des gens utilisent des vieux navigateurs et qu'en conséquence, Jquery est encore utile

[goldbergg]

@bilbop et toi tu as eu le plaisir de tester ES2015 et supérieur ?

Avec sa syntaxe propre et lisible, très loin d'un jquery a base de chaine très rapidement imbuvable.

De découvrir une api rapide a des années lumière de la lenteur de jQuery ?
Parce que oui jQuery est lent, très lent, a code équivalent jQuery met ~10x plus de temps a faire la même chose.
Tu a des centaines de benchmark qui le prouve et des article qui l'explique en details.
Tu peux même tester de ton coté avec les outils de dev présent dans tous les navigateurs.

jQuery est encore beaucoup utilisé principalement pour tous les plug-in et lib qui en sont 100% dépendant.
Combien de site web intègre jQuery uniquement pour avoir un datepicker ou un datatable ?


Faire du from scratch avec une base jQuery ça n'est plus du tous la norme aujourd'hui.
Pour une raison toute simple, il n'y en a aucun intérêt, le JS fait désormais tout très bien tous seul avec des api bien penssé.

JQuery pèse 89,5 ko et est mis en cache, la lourdeur n'est pas un argument.

Quand tu fait un site SPA ou PWA avec des centaines de fichiers, 90ko c'est a prendre en compte

Bref, on a bien compris que t'es un fanboy jQuery qui a peur du changement, mais désolé pour toi, en 2021 jQuery n'a plus de raison d'existé, si se n'est continuer a maintenir toute une base de lib dépendante de cette lib et c'est tous.

L’expérience du monde professionnel m'a montré qu'encore maintenant, des incompatibilités subsistent, qu'encore maintenant des gens utilisent des vieux navigateurs et qu'en conséquence, Jquery est encore utile

Oui, enfin il existe de bien meilleur façon de régler ses problèmes de nos jour en écrivant du code modernes et sans avoir a passer par une surcouche qui va surtout servir a plomber les perf de ton site.

[bilbop]

Quand tu fait un site SPA ou PWA avec des centaines de fichiers, 90ko c'est a prendre en compte

Oui justement, je n'en fait pas.
Je refuse de laisser le soin à mes utilisateurs d'assumer la puissance nécessaire au rendu de la page.
C'est mon backend qui fait le taff, pas mon utilisateur.
Avec ce genre de technos on crée des inégalités fortes chez les utilisateurs en fonction de la puissance de leur machine.
Je génère encore des pages statiques, le navigateur se contente de les lires, c'est léger pour eux.
Le serveur met en cache et c'est bien plus écolo.
Forcément je peux me permettre de 90ko, car il n'y a que ça comme dépendance .... contrairement au SPA et PWA...

Je ne me sens pas forcément fan boy, j'apporte juste un autre son de cloche sur les anciennes technos qu'on veut trop vite enterrer.
Cela serait un autre article proclamant la mort d'une autre techno du genre, je viendrais y apporter de la nuance.

Quand j'étais jeune, je faisais comme vous. Après quelques années passées à coder, on change un peu de point de vue.

Bonne route.

[smarties]

Les sites utilisant jQuery sont généralement lourd, je le vois quand j'utilise un vieux PC chez mes parents sur un site qui utilise jQuery et même le mien parfois.

Il y a longtemps, je suis d’accord, jQuery était très pratique mais maintenant... il est temps de passer à autre chose : maintenant, les navigateurs ont un JavaScript plutôt homogène et il y a aussi WebAssembly.

[smarties]

En sortie d'études il y a un peu de moins de 10 ans, j'étais comme tous les jeunes, toujours un onglet "you don't need jquery" ouvert à rechercher une méthode alternative car plus léger, plus performant, plus moderne ...
L’expérience du monde professionnel m'a montré qu'encore maintenant, des incompatibilités subsistent, qu'encore maintenant des gens utilisent des vieux navigateurs et qu'en conséquence, Jquery est encore utile

Dans des réseaux d'entreprise qui n'ont pas accès à internet, ça peut se comprendre mais maintenant pour surfer sur internet un navigateur trop vieux sera pénalisé.

[parafeu]

Je refuse de laisser le soin à mes utilisateurs d'assumer la puissance nécessaire au rendu de la page.
C'est mon backend qui fait le taff, pas mon utilisateur.
Avec ce genre de technos on crée des inégalités fortes chez les utilisateurs en fonction de la puissance de leur machine.

Du coup ça me parait complètement paradoxal avec ton discours précédent.
Si tu veux faire en sorte en sorte d'avoir le moins d'inégalités au niveau front tu a tout intérêt à utiliser du javascript natif plutôt qu'une lib qui va obligatoirement avoir une consommation de puissance plus élevée.

[Invité]

C'est assez drôle finalement.
JQuery continue de remplir sa mission et parfaitement.
Si JQuery était si inutile, il ne serait pas maintenu à jour.
Oui JQuery était là il y longtemps, et la majorité du code utilisant JQuery est toujours fonctionnel et efficace malgré les années.
JQuery pèse 89,5 ko et est mis en cache, la lourdeur n'est pas un argument.

C'est typiquement ce qui me fait sourire :
Par rapport à quoi à qui ? Qui décide de ce qui est obsolète ou non ?
Qui décide si je dois me mettre à jour ou non ?
Qui peut juger si je suis à jour ou non ?
Qui décide de la mort de ruby, perl, php cobol, framewokX ou libX ?
Personne. Tout simplement personne.
Tant qu'il y 'aura des développeurs qui utilisent des stacks et qui
produisent des applications fonctionnelles il n'y a aucun intérêt à changer.

Ce ne sont que des outils pour accomplir un travail.

Je suis très à jour, comme JQuery l'est encore aujourd’hui en proposant cette mise à jour.
Par exemple, je n'aime pas les arrow function, je trouve que l'async produit du code illisible. Je trouve que le code produit en JS même avec les frameworks récents est difficile à lire et comprendre.
Je trouve que les npm, composer et autres package managers sont dangereux car ils masquent la lourdeurs des dépendances.
Ils obligent par exemple à charger et stocker de gros package qu'on va utiliser à 2%.

Donc non je ne vais pas "devoir me maintenir à jour", je refuse simplement de faire comme soit disant "tout le monde".
Car cela ne me convient pas, et l'aspect "marche forcée" ne me plaît guère plus...
Je me maintiens à jour, je maintiens à jour les applications.
Je le fais juste différemment, mais ce n'est ni moins bien, ni inutile.
Nous sommes nombreux à ne pas suivre la mouvance, ce n'est pas pour rien que les recrutement sont de plus en plus difficiles.
On m'a dit fais du ruby et ruby on rail, j'ai fais du python.
On m'a dit si tu veux bosser apprends Java, j'ai perfectionné mon python.
On m'a dit fais du python et du nodejs (Django, Flask ...), je suis revenu à PHP.
On m'a dit fais du postresql et du mongodb, je suis revenu à Mysql.
On m'a dit le JS c'est de la ***, maintenant c'est le langage soit disant le plus utilisé. Ce sont les mêmes qui crachaient dessus il y'a quelques années.

Je n'écoutes plus, ce genre de chose.

"You do you" comme disent nos amis anglophones, tout ce que tu évoques montre que tu manques complètement de nuance, a un raisonnement égocentré et réfractaire au changement. Que tu n'aimes pas une notation du JS moderne n'est en aucun cas un argument. Quand quelqu'un te dis "fais du Ruby" tu sais que c'est pas un règle absolue ? Tu as préféré faire du Python grand bien te fasse, tout le monde s'en fout j'ai envie de dire.

Le réalité c'est que le JS d'aujourd'hui a comblé un grand nombre de ses faiblesses passées et que les API des navigateurs sont pour la plupart standardisées. Ce sont les problèmes que résolvait jQuery, les problèmes n'existent plus donc l'outil n'a plus vraiment de sens. Et au passage jQuery n'est pas inutile puisque beaucoup de projets l'ont toujours en dépendance.

Maintenant tu veux toujours l'utiliser ? Encore une fois libre à toi, ça marchera parfaitement. En l'occurrence là c'est pas jQuery VS un autre outil, c'est jQuery vs JavaScript/CSS, donc on parle de retirer une couche de complexité pas d'en changer une pour une autre. Si tu souhaites mettre des œillères et ne pas voir les faits c'est ton choix, les faits sont les faits.

[Gunny]

Oui, il est important que jQuery soit maintenu à jour, mais si vous regardez les derniers changelogs, c'est du léger : principalement des corrections de bugs ou de failles de sécurité, et quelques nouvelles fonctionnalités de type qualité de vie.

jQuery est sur le chemin de la sortie, mais il est encore très répandu et il va continuer à être là encore un moment. Si vous bossez sur un site web qui a plus de quelques années, jQuery va très probablement être de la partie. Le refactoring n'est pas gratuit, et pour des questions de maintenance vous allez devoir continuer à en écrire. Même sur des nouveaux projets, il est facile de se retrouver avec une dépendance à jQuery quelque part (*tousse* bootstrap *tousse*), mais au moins vous n'êtes pas obligés de vous en servir.

jQuery est-il dépassé ? Oui, clairement, en 2021 les fonctionnalités de JS l'ont largement rattrapé, donc il n'y a pas vraiment de raison de se trimballer une dépendance redondante si on peut l'éviter. Mais jQuery possède une énorme inertie et fonctionne très bien, donc il va être avec nous encore un bout de temps à mon avis. Probablement plus longtemps que certains frameworks actuels.

[ABCIWEB]

Oui si l'on ne considère que les sélecteurs, jQuery n'est plus très utile, la syntaxe est globalement un peu plus courte mais cela ne justifie pas une lib. Par contre jQuery dispose d'effets comme des "slide", des "fadein" etc. que l'on pourrait faire en combinant css avec javascript mais c'est beaucoup moins portable, de même j'utilise jQuery UI pour les interfaces administrateur, faire du drag and drop etc, donc je ne suis pas motivé pour changer étant donné que cela fonctionne bien. Cela dit je fais aussi beaucoup de javascript vanilla, je mixte les deux suivant les besoins / le contexte, mais étant donné que c'est la seule librairie javascript que j'utilise je ne cherche pas non plus à m'en séparer.

Si je devais repartir de zéro aujourd'hui peut-être j'utiliserais Vue.js pour la création de formulaires. D'un autre côté jQuery est plus généraliste même s'il est moins puissant pour certaines fonctionnalités. Bref pour moi jQuery reste utile pour qui ne veut pas multiplier l'utilisation de différentes librairies. Quant aux frameworks qui imposent une structure de code ils ne m'intéressent pas, ce qui ne veut pas dire que je les dénigre mais en tant que développeur solo je préfère la souplesse avant tout.

[air-dex]

jQuery vient d'une époque où tout le monde faisait un peu ce qu'il voulait et où il a facilité les choses en prenant à son compte les différences. Certes il parait moins utile aujourd'hui car les normes sont davantage respectées. Mais tout le monde n'est pas pour autant sur la même version du même navigateur et ne s'y met pas d'un coup de baguette magique. Il subsistera toujours des différences, des normes ultra-récentes qui ne seront pas encore implémentées par certains navigateurs et pas prises en charge par les anciennes versions du navigateur où c'est désormais implémenté, sans compter des changements qui pourront faire que c'est différent sur une ancienne version où c'était implémenté... Bref il y aura toujours des différences à la pointe de la technologie malgré tout, et tant qu'il y aura ces différences là on aura toujours besoin de jQuery pour les prendre à son compte et nous faciliter la tâche. Il sera donc increvable.

Il faut bien se rendre compte que jQuery a été conçu à une époque ou chaque navigateur faisait sa petite sauce et que c'était un bordel sans nom de développer un site qui fonctionne sur tous les navigateurs. Ça a également été incroyablement utile lorsque l'AJAX est apparu, simplifiant tout le bordel et à nouveau aidant à la compatibilité entre navigateurs. Pour couronner le tout, beaucoup de fonctions d'aides pour le côté JS qui était un bordel sans nom à cette époque et, encore une fois, non standardisé entre les navigateurs, ont simplifié la vie de tous les devs.

Depuis, et heureusement, les navigateurs ont largement harmonisés leurs APIs et même si Google fait des siennes en implémentant des trucs non standards dans son coin (forçant la main des autres mais c'est un autre sujet) au moins les bases sont standardisées depuis pas mal d'années. Tout ce qui est sélecteur CSS natif, qui ressemblent furieusement à la syntaxe de jQuery, ainsi que l'API fetch, fonctionnent très bien. Le JS s'est également amélioré considérablement.

Du coup il faut bien se rendre compte que jQuery a rempli sa mission parfaitement, je pense que ça a été un facteur déterminant sur le chemin qui à mené à aujourd'hui et aux standards actuels, mais qu'il faut reconnaître que ce n'est plus très utile de nos jours. Alors certes les devs qui utilisent jQuery depuis 15 ans vont devoir se mettre à jour mais ca fait parti du job non ?

Et qui sera là le jour où Google va se mettre à trop diverger et où il faudra quelque chose pour ne plus passer son temps à faire du if (weAreOnChrome) { /* ... */ } comme avec IE 6 fut un temps ? Gigi Couéry !

Oui justement, je n'en fait pas.
Je refuse de laisser le soin à mes utilisateurs d'assumer la puissance nécessaire au rendu de la page.
C'est mon backend qui fait le taff, pas mon utilisateur.
Avec ce genre de technos on crée des inégalités fortes chez les utilisateurs en fonction de la puissance de leur machine.
Je génère encore des pages statiques, le navigateur se contente de les lires, c'est léger pour eux.
Le serveur met en cache et c'est bien plus écolo.
Forcément je peux me permettre de 90ko, car il n'y a que ça comme dépendance .... contrairement au SPA et PWA...

Je ne me sens pas forcément fan boy, j'apporte juste un autre son de cloche sur les anciennes technos qu'on veut trop vite enterrer.
Cela serait un autre article proclamant la mort d'une autre techno du genre, je viendrais y apporter de la nuance.

Quand j'étais jeune, je faisais comme vous. Après quelques années passées à coder, on change un peu de point de vue.

Bonne route.

Et puis s'offusquer des 90 ko de jQuery dans des projets "npm install"-"350 Mo de téléchargements de dépendances plus tard".

Cela doit faire pas mal de temps que tu n'as plus codé en JS sans librairie pour dire ça... Les manipulations DOM par exemple, c'est aussi simple aujourd'hui qu'en jQuery très honnêtement. Pour faire de l'ajax, on a fetch en JS qui fait largement l'affaire maintenant, avec un polyfill disponible pour être compatible partout.

Aujourd'hui jQuery c'est de plus en plus dépassé et c'est un fait, je m'en sers toujours dans certains projets donc je ne crache pas dessus ça a réellement simplifié l'utilisation du JS pendant très longtemps, mais désormais on peut faire aussi facilement en JS tout ce qu'on peut faire en jQuery. Donc c'est une librairie qui reste lourde et qui n'apporte plus grand chose aujourd'hui.

Pour les projets comme Bootstrap c'est très bien de s'en passer et d'éviter au maximum les dépendances, c'est valable pour n'importe quel projet. Je prends l'exemple d'un site vitrine tout simple, auparavant il fallait nécessairement jQuery pour faire un simple modal ou rendre responsive la navbar, c'est quelque chose de très lourd pour pas grand chose. L'utilisation de Bootstrap n'impose plus cette librairie et c'est très bien, rien n'empêche de continuer à utiliser jQuery dans le futur si voulu !

Donc je pense que ce n'est plus nécessaire d'utiliser jQuery, continuer à l'utiliser c'est avoir la flemme de se mettre à jour avec les dernières versions ECMAScript tout simplement

Cependant la où on reste d'accord c'est que jQuery est pratique car compatible avec tous les grands navigateurs et même les anciens. Mais il est très facile aujourd'hui de compiler son code JS afin d'y ajouter les polyfills nécessaires automatiquement aussi.

jQuery n'a pas besoin de s'embarrasser de polyfills, lui.

Bootstrap c'est l'héritier de jQuery UI. jQuery est bien plus que jQuery UI. De plus niveau poids BS est il plus lourd ou bien plus léger que jQuery UI ?

L'argument ES n'est pas valide. Les nouvelles technologies à la pointe de la norme, c'est bien. Que les navigateurs les prennent toutes correctement en charge et sans avoir besoin de polyfill, c'est mieux. Or il se passe du temps entre les deux, un temps où jQuery sera juste indispensable si tu veux utiliser la nouvelle techno.

jQuery c'est aussi une syntaxe claire, concise et lisible. Peut-on toujours en dire autant en JS vanilla ? J'attends toujours d'y voir quelque chose du style "$.get(url, data)" pour faire une simple requête GET. Merci jQuery de nous offrir ce sucre syntaxique, à l'instar de ce que la norme ES6+ nous a offert pour d'autres choses.

Bref tout ça pour dire que jQuery n'est pas et n'a pas à être opposé à des choses plus récentes que lui. Au contraire il peut très bien se marier avec et a toujours autant sa place.

Il y a longtemps, je suis d’accord, jQuery était très pratique mais maintenant... il est temps de passer à autre chose : maintenant, les navigateurs ont un JavaScript plutôt homogène et il y a aussi WebAssembly.

WASM est encore limité. Il lui manque une manipulation performante du DOM (comparée à JS) pour être pertinent. Or la manipulation du DOM est quand même quelque chose que l'on opère vachement souvent dans une page Web.

[Invité]

Et qui sera là le jour où Google va se mettre à trop diverger et où il faudra quelque chose pour ne plus passer son temps à faire du if (weAreOnChrome) { /* ... */ } comme avec IE 6 fut un temps ? Gigi Couéry !

Mes félicitations pour savoir prédire l'avenir, tu es très fort.

Et puis s'offusquer des 90 ko de jQuery dans des projets "npm install"-"350 Mo de téléchargements de dépendances plus tard".
jQuery n'a pas besoin de s'embarrasser de polyfills, lui.

La plupart des polyfills sont bien plus légers que jQuery, c'est pas du tout un argument pour jQuery. Et dire X est nul donc Y qui est moins nul c'est bien, osé comme raisonnement. De plus tu sembles confondre ce que NPM télécharge sur ta machine et la compilation finale qui est envoyée au client, ce qui démontre une belle ignorance dans le domaine.

Bootstrap c'est l'héritier de jQuery UI.

Alors non, genre pas du tout. Ce sont des bibliothèques d’éléments UI basées sur jQuery certes mais la comparaison s'arrête là. De plus c'est pas le sujet on parle de jQuery là pas de jQuery UI.

L'argument ES n'est pas valide. Les nouvelles technologies à la pointe de la norme, c'est bien. Que les navigateurs les prennent toutes correctement en charge et sans avoir besoin de polyfill, c'est mieux. Or il se passe du temps entre les deux, un temps où jQuery sera juste indispensable si tu veux utiliser la nouvelle techno.

Encore une fois non, les navigateurs modernes sont généralement en avance sur les normes, et ajouter un polyfill occasionnel est beaucoup plus simple et léger que de mettre jQuery dans le projet, surtout que le jour ou la feature est implémentée par tous les navigateurs tu as juste a enlever le polyfill et tout marche.

jQuery c'est aussi une syntaxe claire, concise et lisible. Peut-on toujours en dire autant en JS vanilla ? J'attends toujours d'y voir quelque chose du style "$.get(url, data)" pour faire une simple requête GET. Merci jQuery de nous offrir ce sucre syntaxique, à l'instar de ce que la norme ES6+ nous a offert pour d'autres choses.

Ah, "fetch(url)" c'est pas suffisamment simple ? Et dire que jQuery possède une syntaxe plus claire que le JS moderne c'est un comble.

WASM est encore limité. Il lui manque une manipulation performante du DOM (comparée à JS) pour être pertinent. Or la manipulation du DOM est quand même quelque chose que l'on opère vachement souvent dans une page Web.

Wasm est pertinent mais ne sert pas à manipuler le DOM, strictement aucun rapport avec jQuery.

[mayer_450]

JQuery est completement dépassé par les nouveaux framework/librairies .

La clef c'est de restez techno-independant !