Discussion :

[danielhagnoul]

Peut-on se passer de jQuery ?
Avant de dire oui, regardez ce qu'il fait pour vous !

Vu les performances des navigateurs dignes de ce nom et l'amélioration du JS (1) plusieurs ont le sentiment que l'on peut se passer d'une bibliothèque comme jQuery. D'autres pensent que jQuery est trop lourd, ils recommandent d'adopter une bibliothèque minimaliste.

Afin d'éviter les bogues dans toutes les circonstances, s'en passer exigera de vous une veille technologique permanente sur les particularités des navigateurs.

La manipulation du DOM est le point fort de jQuery, avec lui vous n'avez pas besoin d'être un expert des particularités du DOM pour développer vos codes.

Pour l'équipe de développement de jQuery, tenir compte de tout cela est un travail sans fin, car les navigateurs et les recommandations du W3C évoluent en permanence.

Les développeurs d'une bibliothèque alternative ou minimaliste se heurteront aux mêmes écueils.

Liste des solutions spécifiques à un navigateur pour jQuery 2.1.x

(1) ES5 et les rustines permettant d'utiliser une large part du futur ES6

Source

[Kaamo]

L'empire jQuery Contre-Attaque !

Notamment You Might Not Need jQuery qui a fait couler beaucoup d'encre, euh, de tweets la semaine dernière.

D'ailleurs, les gars derrière You Might Not Need jQuery ont ajouté le lien vers ce doc. De bonne guerre

[danielhagnoul]

L'empire jQuery Contre-Attaque !

[Darkaurora]

Je dois dire qu'utilisant jQuery et d'autre lib depuis plus de deux ans, Il est quand même confortable d'avoir a disposition des outils efficaces.

Après avoir pris connaissance du site "You Might Not Need jQuery" c'est vrai que la différence n'est pas énorme mais je maintiens qu'il est plus facile de se souvenir d'une ligne de code plutôt que de 4.

Pour ce qui est des performances, côté client vous êtes normalement tenu d'en faire le minimum pour des raisons de fluidité.

Maintenant j'ai appris le JS avec jQuery, j'en apprend encore tout les jours et la manipulation du DOM est enfantine avec une bibliothèque tel que jQuery.

Petit point noire, c'est la maintenabilité de la lib et les bugs notamment avec les mises à jours et les méthodes dépréciées. Mais rien de bien méchant car la documentation est très bien fournit.

[SylvainPV]

Il ne faudrait pas voir l'abandon de jQuery comme une "régression". Si la bibliothèque est si populaire, c'est que les contributeurs du projet font preuve d'une compétence et d'une fiabilité exemplaire. Ils disposent de leurs propres solutions de test, QUnit et TestSwarm, et ont un panel de test gigantissime. jQuery est utilisé sur plus de la moitié des 10.000 sites les plus fréquentés, et 75% du top 100 : http://royal.pingdom.com/wp-content/...ats-1024px.jpg

En revanche, on peut songer à la période post-jQuery: migrer de jQuery à une solution plus complexe. Par exemple, troquer la manipulation du DOM et le binding d'évènements à une bibliothèque de templating/data-binding comme celle qui a fait parler d'elle pas plus tard qu'il y a deux jours, Vue.js.

Bien que quelques helpers jQuery continueront à beaucoup servir (AJAX, dimensionnement, deferred), les key-features de jQuery sont moins indispensables qu'avant : Sizzle a amené document.querySelector, l'API animation est peu à peu remplacée par les transitions CSS... jQuery a été le ciment du web client pendant près d'une décennie, à recoller les morceaux des standards bien amochés d'un navigateur à l'autre. Maintenant que la situation est un peu plus supportable, on peut commencer à envisager des approches différentes. Donc je dirais que oui, on peut légitimement se passer de jQuery, mais à condition de passer à "autre chose".

[Kaamo]

on peut légitimement se passer de jQuery, mais à condition de passer à "autre chose".

Exactement. Et avoir conscience de ce que jQuery "répare" (cf. document ci-dessus)

Sympa Vue.js !

[fredoche]

En quoi serait-ce lourd ? pour ceux qui le pensent. Taille du fichier de bibliothèque ?

On peut s'en passer, j'ai fait des applis pendant bien 10 ans sans.
Mais je vois ce que je peux faire avec Et je peux me concentrer sur la logique de mon programme, pas sur les particularités de X plate-formes.

Je dois toujours supporter IE8, en rapport au site cité par Kaamo. Institutionnels FF liés à l'état comme client, des moyens informatiques, mais des DSI qui maintiennent les postes à des niveaux de versions ante-diluviens.
J'imagine pour la sécurité, mais j'ai peur que cela joue contre eux.

Et la bascule IE6-IE8 pour mon gros client est toute récente il me semble, 2 ans pas plus. Je suis d'ailleurs bloqué à jquery v1.x pour le moment

Au demeurant bizarre ce genre de mouvement au sein de la communauté javascript.
Je dirais presque " à quoi ça sert ?" ce genre de question ? Les gens (développeurs en principe pro) ne peuvent-ils se la poser eux-même ?

[SylvainPV]

En quoi serait-ce lourd ? pour ceux qui le pensent. Taille du fichier de bibliothèque ?

Oui, en particulier pour le contexte Web mobile. Aussi, jQuery propose une API non structurante, c'est à dire qui n'impose pas de modèle de conception. Ça rend la bibliothèque plus polyvalente, mais le code en aval plus lourd. Pour reprendre l'exemple de VueJS, regarde la taille du code de TodoMVC en comparaison avec jQuery :
https://github.com/yyx990803/vue/blo...omvc/js/app.js
https://github.com/tastejs/todomvc/b...uery/js/app.js

Au demeurant bizarre ce genre de mouvement au sein de la communauté javascript.
Je dirais presque " à quoi ça sert ?" ce genre de question ? Les gens (développeurs en principe pro) ne peuvent-ils se la poser eux-même ?

Eh bien c'est le cas, ce sont les développeurs qui parlent ici. Et tout bon développeur se doit de remettre en question régulièrement le choix de son outillage, en s'ouvrant à d'autres alternatives.

[fredoche]

regarde la taille du code de TodoMVC en comparaison avec jQuery :

du simple au double si l'on se contente de comparer les chiffres

ayant commencé à une époque où avoir un modem 28.8 kbps était un summum en terme de matériel, je me demande si on se trompe pas un peu de sujet.
Donc à cette époque, le 1er fichier était chargé durant la première seconde et le second avant la seconde seconde.

Alors maintenant entre minifier, gzip, cache du navigateur, et probable compression/proxy-cache du FAI "mobile"

En fait pour préciser c'est bien la démarche de ce site : http://youmightnotneedjquery.com/
que je trouve étonnante. Comme un manifeste, une espèce de mouvement qui se sent le devoir de rallier des gens à sa cause. Et le décompte twitter/github

Enfin bon c'est pôôôô grave

[imikado]

Je ne pense pas que l'on puisse faire une réponse stricte:
Selon l'application il sera bénéfique d'utiliser jQuery ou non.
J'ai un collègue qui à l'habitude de systématiquement installer et utiliser jQuery sans bien connaitre javascript, je lui par exemple expliqué comment faire un "simple" innerHTML
On installe pas jQuery juste pour faire des innerHTML

Il faut savoir estimer à partir de quel moment on a besoin de cet outil

[jojosbiz]

Je réponds "Oui" sans hésiter et sans préambule.

Je n'utilise JQuery qu'une fois de temps en temps et seulement pour la partie "effets".

Pour le reste, j'avoue que je déteste voir des "$(...)" de partout dans un code et que je préfère faire du javascript "brut".

C'est bien plus rigolo.

[Saverok]

Aucune API / librairie n'est indispensable
L'informatique évolue sans cesse et les développeurs adaptent leurs outils ou en change si besoin
Je trouve sain de se remettre en question et de ne pas rester sur des acquis
La navigation mobile et tous les nouveaux usages qui vont avec nous obligent à repenser notre métier et c'est justement ce qu'il me plaît.
Pour le moment, jQuery remplit bien le boulot que je lui demande mais je reste en veille, comme toujours, pour toutes les API que j'utilise.

[tomlev]

Je suppose qu'on peut s'en passer (la raison la plus évidente est que ça n'a pas toujours existé et qu'on s'en sortait quand même), mais pour moi qui ne fait du JS que très occasionnellement, et presque toujours pour des tâches de manipulation du DOM, je dois dire que jQuery facilite carrément la vie... Du coup je n'essaie même plus de m'en passer.

[koyosama]

Je dirais non logiquement et oui personnellement. Pour faire des des petits trucs, je peux sans, j'ai juste à utiliser Vanilla JS pour mes requêtes Ajax. Mais les plugins que j’utilise, dépend tous jQuery donc voila pourquoi mon non définitif.

Rien que Primefaces que j'utilise en ce moment, est fait totalement avec jQuery. En fait, pas mal de Framework ou plugins js se basent sur jQuery. Bon je n'ai pas trop le choix .

En plus certains développeurs croient que jQuery est un langage. On est bien sorti de l'auberge ... .

[Traroth2]

Le truc qui commence à devenir dérangeant avec Javascript, c'est qu'on est apparemment en train de passer à un mode de fonctionnement avec un nouveau framework à la mode par semaine, et en gros on attend de nous de tout migrer systématiquement. Personnellement, j'ai d'autres envies dans la vie que de migrer des applications de JQuery à Angular et d'Angular à autre chose. C'est pas très professionnel, en plus. Je n'ai rien contre l'émergence de nouveaux outils, bien au contraire, mais il faut que les choix technologiques soient un minimum pérennes, ce qui veut dire qu'il faut une bonne raison pour les remettre en cause, et pas juste un effet de mode.

[transgohan]

Toute bibliothèque n'est pas indispensable.
Pour ma part je n'utilise jQuery que si ce dernier m'apporte un plus.
Si c'est rajouter 10kio à chaque page pour simplement utiliser une méthode de jQuery qui se ferrait en JS pur (même si c'est l'équivalent de 10 lignes) je ne vois pas l'intérêt...

[LSMetag]

Je conçois tout à fait que JQuery simplifie beaucoup l'utilisation du Javascript, en particulier du DOM. Mais en effet, on se heurte à la problématique expliquée par SylvainPV. Certains (comme mes parents) sont toujours en RE-ADSL (512k), d'autres sont encore en 56k. Dans le village de mes parents, le maximum c'est 2mb. Alors oui un Javascript généré par JQuery, ça se sent (à la fois les performances du code généré que le temps de génération en lui même). On perd jusqu'à plusieurs secondes pour certaines actions. Quand un site est bourré d'effets Javascript, ça impacte de manière non négligeable l'expérience utilisateur. Et je ne parle même pas de la charge serveur, où l'on va faire chercher à chaque utilisateur du site la bibliothèque JQuery, ce qui est une source de ralentissement supplémentaire (en 512k, on télécharge à 60kbps).

Comme vous l'avez sans doute remarqué, je suis devenu fan du langage Dart, qui lui aussi simplifie grandement l'utilisation de Javascript, mais qui a comme avantage une conversion en Javascript beaucoup plus performante que JQuery, et qui permet pour les navigateurs le supportant (ou côté serveur), de l'utiliser "pur", au travers d'une VM, dont les performances sont très supérieures au Javascript de base.

Donc : Oui pour les JQuery-like qui sont pratiquement indispensable pour les non experts de Javascript. Mais non pour JQuery en ce qui me concerne, notamment pour des problématiques de performances, mais également parce que je préfère le paradigme objet de Dart.
Oui également pour les AngularJS/AngularDart qui sont très intéressants pour structurer le code client (maintenabilité, architecture,...), ce que ne permet pas spécialement des Frameworks comme JQuery.

[Zefling]

Perso, ça dépends du projet. Si j'ai besoin de fait juste deux trois truc minimes, je ne fais pas mettre une API énorme dernière que je ne vais même pas utiliser à 1 %. Pas besoin d'utiliser un bulldozer pour déplacer un trois cailloux.
Puis, ce que certains utilise souvent avec $(''), si l'on ne pousse pas trop loin, ça peut se reproduire très facilement avec querySelectorAll. Par contre, j'ai besoin d'AJAX à tout vas, d'effets, etc. Jquery peut être une bonne solution. Il faut savoir faire les deux, car si un jour on tombe sur un projet sans Jquery, c'est plus facile de s'adapter. Et puis, de plus en plus souvent, l'excuse IE6, IE7 voir IE8 ne fonctionne plus.

[fredoche]

Je conçois tout à fait que JQuery simplifie beaucoup l'utilisation du Javascript, en particulier du DOM. Mais en effet, on se heurte à la problématique expliquée par SylvainPV. Certains (comme mes parents) sont toujours en RE-ADSL (512k), d'autres sont encore en 56k. Dans le village de mes parents, le maximum c'est 2mb. Alors oui un Javascript généré par JQuery, ça se sent (à la fois les performances du code généré que le temps de génération en lui même). On perd jusqu'à plusieurs secondes pour certaines actions. Quand un site est bourré d'effets Javascript, ça impacte de manière non négligeable l'expérience utilisateur. Et je ne parle même pas de la charge serveur, où l'on va faire chercher à chaque utilisateur du site la bibliothèque JQuery, ce qui est une source de ralentissement supplémentaire (en 512k, on télécharge à 60kbps).

Non en ReADSL, en 512 k on télécharge à 512 kbps par seconde et 64 ko/s. On passe donc potentiellement une 20aine de fichiers de 3 ko dans la seconde.( 64 * 8 =512)
Ceci étant la bibliothèque minifiée fait entre 80 et 90 ko selon la version (1 ou 2)

Quand au 56k, il ne fonctionne en réalité que sur des lignes qui sont de bonne qualité. Si la ligne n'est pas éligible à l'adsl, elle est soit trop longue, soit multiplexée. Si elle est trop longue, peu de chances de synchroniser à 56 kbps. Si déja tu as du 28.8 kbps, estime toi heureux.


Connaissant bien le problème puisque moi-même je suis doté d'une ligne de 9km absolument inéligible aussi bien à l'ADSL qu'au 56kbps RTC, il existe des solutions qui permettent de sortir du bas-débit, et avoir du haut, voir du très haut débit, notamment pour des gens qui savent faire un peu d'informatique (généraliste) et qui n'ont pas peur de se prendre par la main. Je ne parle pas de satellite.

Ensuite qu'un site soit bourré d'effets javascript, ça n'a pas de lien avec jquery, je ne crois pas que ce soit en soit une bibliothèque source de ralentissements, leurs algos sont plutôt optimisés.
Et délivrer le fichier jquery plutôt qu'un autre fichier ou une autre image, ça n'a pas plus de conséquence sur un serveur web que la taille du fichier. Un serveur web sert à ça. Délivrer du fichier statique. C'est quasi sans conséquence en terme de charge pour un serveur http.

Si le serveur web est bien configuré (en gros par défaut il l'est), la bibliothèque pourra être "gzipée" avant transfert http et ensuite mise en cache par le navigateur, elle ne se chargera qu'une seule fois pour un chemin donné et une session navigateur donnée. Elle ne générera même pas de nouvelle requête http, vous pouvez vérifier... Même un F5 basique ne recharge pas la bibliothèque (comme les autres fichiers mis en cache: css, js, images...), le serveur répondra "HTTP 304 not modified", et c'est vraiment en forçant la mise à jour du cache (shift+F5)qu'on recharge cette bibliothèque.

En plus de ça, toutes les versions de jquery sont proposées hébergées en CDN, ce qui offre un bénéfice inter-sites et latence énorme, il y a au moins 4 CDN officiels de listés sur jquery.com.

[Shuty]

jQuery est un outil très puissant mais aussi très synthétique. Comme on peut le lire souvent, les gens se disent même programmer en jQuery alors qu'au fond ca ne reste que du JS.

Je pense que cet outil est excellemment et sa communauté l'est aussi. +1