Doit-on encore utiliser jQuery en 2017 ?

Cet article est libre d'accès pour tous grâce à ceux qui soutiennent notre blog indépendant.

J'ai donné cours de JavaScript à de jeunes 3ème année. Dans le programme prévu par l'école, je dois notamment leur apprendre jQuery.

Très vite se sont posées les questions de est-ce que c'est bien, est ce que c'est utile, est-ce que l'on doit l'utiliser.

Si vous souhaitez avoir la réponse courte que j'ai donné aux élèves et que je donne à qui en discute avec moi, dans l'ordre ça donne : oui, oui, non. Pour les arguments c'est en dessous.

Est-ce que c'est bien ?

Je ne peux pas dire que jQuery n'est pas bien. À une époque c'était même ce qui se faisait de mieux. Le JavaScript stagnait, la communauté avait besoin d'améliorations et la communauté a développé ces améliorations.

Donc oui, jQuery c'est bien. On parle d'une bibliothèque qui nous a fait oublier XMLHttpRequest quand même ! Elle a grandement simplifiée le langage et nous a épargné les actions redondantes comme la modification du CSS, des attributs, la sélection des éléments du DOM.

Ce sont aussi les premiers arguments que l'on me donne lorsque j'en discute avec d'autres développeurs. Mais ce n'est pas ça que je remet en cause.

Est-ce que c'est utile ?

Mon principal argument pour l'utilisation de jQuery est la gestion de la rétro-compatibilité. On n'y pense pas toujours lorsqu'on les utilise tellement elles sont simples mais les fonctions de jQuery sont blindées niveau rétro-compatibilité.

Toutes les méthodes possibles pour faire de l'AJAX par exemple, sont implémentées dans jQuery. Ce qui fait que cette librairie fonctionne sur de vieux navigateurs et même sur IE. Ce sont des cas qui ne nous gêne pas lorsqu'on utilise jQuery, il s'en occupe : quel navigateur ? quelle version ? Est-ce qu'il faut vérifier les activeX ?

Oui, jQuery peut-être utile pour développer des choses relativement avancées qui doivent être compatibles avec de vieux navigateurs.

Est-ce qu'il faut l'utiliser ?

C'est ici que je vais vraiment devoir m'expliquer. Je ne pousse pas les gens à apprendre en détail et/ou développer en jQuery.

Ce qui m'embête le plus avec cette librairie, c'est qu'elle réécrit trop le langage en lui même. Enormément de méthodes natives ont leur pendant jQuery.

Sauf qu'aujourd'hui en 2017 on se retrouve avec une masse de développeurs jQuery qui ne savent plus développer sans. Ils ne savent plus développer en JavaScript.

Et aujourd'hui en 2017 le langage à évolué. jQuery a été développé parce que le langage avait des lacunes, ces lacunes ont été comblées en 2015 par une nouvelle version d'EcmaScript : jQuery a moins d'utilité.

Il y a maintenant beaucoup moins de choses "plus compliquées à faire" en JS natif qu'en jQuery. Et c'est sûrement d'ailleurs parce que Ecma International s'est beaucoup inspiré de ce qu'avait fait la communauté pour la nouvelle version de son standard.

Sur les projets web sur lesquels je bosse à Econocom, je suis développeur fullstack javascript. S'il y a une chose que j'aime à surveiller, c'est que les dépendances utilisées au back pour une même fonctionnalité soit aussi utilisées au front et inversement.

Je n'aime pas devoir me rappeler que les tests du back tournent avec mocha alors qu'au front c'est jasmine. De même avec cucumberjs et protractor, jQuery et jS natif. C'est source d'erreur.

Je n'utilise donc plus jQuery depuis un moment maintenant et j'invite les gens à en faire de même.

Mais reste encore la rétro-compatibilité avec les anciens navigateurs. Et vous savez quoi, je pense que c'est un faux problème.

Tout d'abord parce que le temps à passé et que les navigateurs qui avait besoin d'une attention particulière à l'époque de l'écriture de jQuery ne sont pour la plupart plus maintenus/utilisés. Leurs parts de marché sont devenues si négligeables qu'il en devient contre-productif de devoir les supporter.

Bien-sûr cet argument dépend de la cible de votre application. Il est principalement valable pour les applications pour particuliers. Si vous développez une application pour des clients utilisants IE5, ne tenez pas compte de celui-ci.

Ensuite, des outils tels que babeljs ou polyfill.io vont nous permettre de générer du code compréhensible pour les anciens navigateurs[1].

Il est aujourd'hui possible d'écrire notre code en tenant compte des dernières versions des standards sans même attendre que les navigateurs ne les implementent. Ensuite on n'a plus qu'à appuyer sur un bouton pour que notre code devienne compatible avec notre cible. Pourquoi s'en priver ?

Le sentiment que j'ai au sujet de jQuery lorsque j'écris ces lignes, c'est qu'il est devenu quelque peu inutile dans ce pourquoi je l'utilisais. Il fonctionne bien, très bien même mais son travail n'est plus vraiment nécessaire. Il ne fait que rajouter une couche d'abstraction supplémentaire.

Donc oui, jQuery était bien. Oui, jQuery était utile et peut encore l'être dans certain cas très particulier mais non, je n'encourage pas son utilisation en 2017.


  1. Ceci est vrai dans la limite du raisonnable. Certaines fonctionnalités ne sont pas transposables dans des versions antérieures du langage mais dans ces cas jQuery ne fait pas plus de miracle. ↩︎

Rejoins 250+ développeurs de notre liste de diffusion et sois reçois les articles directement dans ta boite mail.

S'inscrire à la newsletter

Aucun spam. Désabonnes-toi en un seul clic à tout moment.

Si vous avez des questions ou des remarques/conseils, n'hésitez pas à laisser un commentaire plus bas ! Je serais ravis de vous lire. Et si vous aimez l'article, n'oubliez pas de le partager avec vos amis.