Avons-nous encore besoin de jQuery ou devrions-nous nous en tenir au script?

Lorsque jQuery est apparu en 2006, c'était l'un des rares frameworks qui permettait aux développeurs d'écrire Javascript plus rapidement en utilisant le raccourci pour les fonctions et en permettant au daisychaining de réduire la répétition.

J'avais utilisé scriptaculeux (construit sur Prototype) sur des projets web précédemment et avait assisté à des conférences, y compris @media Ajax 2007 où j'ai rencontré des gens comme Brendan Eich qui avait créé EcmaScript / Javascript chez Netscape et John Resig qui avait créé jQuery en 2006, un concurrent de script.aculo.us de Thomas Fuchs qui «... vous fournit des bibliothèques JavaScript d’interface utilisateur multinavigateur faciles à utiliser pour faire voler vos sites web et applications web». Web 2.0 est né à cette époque et la simple fonctionnalité Ajax était l'un de ses composants clés, que jQuery et Prototype ont activé.

À son apogée, jQuery a été utilisé sur 80% des 1 million de sites Web les plus populaires (https://en.wikipedia.org/wiki/JQuery#cite_note-:1-19) et a été livré avec des CMS communs, y compris Joomla (après s’être éloigné de MooTools dans la version 4)

Jusqu'à récemment, jQuery était le composant omniprésent dans de nombreux projets, mais j'ai commencé à rencontrer de jeunes développeurs qui criaient à propos d'Angular.js ou de Vue ou de React, selon ce qui semblait être le cadre en vogue cette semaine-là. Ne vous méprenez pas, je comprends comment ces frameworks/bibliothèques peuvent bénéficier aux projets, car je passe des heures libres à nouiller chez React Native comme moyen de créer des applications mobiles.

Ce n'est que cette semaine que j'ai dû reconstruire un site Web qui avait trouvé son chemin sur la Wayback Machine sans sauvegarde. En mettant mon chapeau d’ingénieur inverse, je me suis rapidement attelé à la tâche de déterminer comment le développeur initial s’était acquitté de certaines tâches. Je me suis un peu penché sur le CSS et j'ai maudit l'archive pour ne pas m'avoir laissé entrer dans chaque script utilisé pour faire fonctionner le frontend.

Et j'ai choisi d'utiliser jQuery pour que le site fonctionne rapidement, avec ses menus animés et l'image de l'effet Burns qui s'estompe. Je l'ai fait parce que pour moi, j'entrais dans la tête du développeur qui avait commencé le projet. Mais dans le fond de mon esprit, je me sentais un peu coupable de sauter paresseusement et d'utiliser une bibliothèque de code que, peu importe si j'utilise une fonction, ou 3 douzaines, je dois charger toute la bibliothèque de base.

Seulement pour ce projet jQuery est préchargé, alors pourquoi le sentiment de culpabilité? Eh bien, si j’utilise du Javascript brut, il est déjà dans le navigateur, comme HTML, et je dis simplement au navigateur comment travailler avec mon site web. Alors, pourquoi dois-je charger jQuery pour faire la tâche pour moi, potentiellement gonfler mon site (même par un petit peu) et affecter le score de vitesse de page tout important? Une partie de la raison en est son héritage. De nombreux plugins et extensions utiliseront non seulement jQuery, mais Bootstrap comme base pour les mises en page et le style.

Pour quoi utilisons-nous JavaScript?

• Ajax : appeler des données dans une page sans avoir à les recharger
• Interactions : Manipuler le DOM pour afficher / cacher des éléments
• Animations

La performance est l'une des clés

Est-ce la raison pour laquelle les développeurs s'éloignent de jQuery? Pagespeed / Performance?

J'ai commencé à penser que c'était une question facile à répondre sur la façon dont les bibliothèques et les frameworks devraient être remplacés par du JavaScript pur. D'une part, les bibliothèques aident à simplifier le processus de développement et veulent s'assurer de la compatibilité entre navigateur / plate-forme.

Mais JavaScript a mûri au fil du temps et l'une des raisons de l'utilisation de jQuery était le comportement non standard de certains navigateurs Web. Vous souvenez-vous d'avoir à faire des vérifications supplémentaires ou des exceptions pour Internet Explorer?

Remplaçons-nous jQuery dans nos projets?

Avant de sauter et de supprimer jQuery dans l'ensemble, pensez à ce qu'il fait pour vous.

Un facteur important pourrait être ce qu'est le projet.

Ensuite, considérez combien de travail supplémentaire il créerait pour coder ce dont vous avez besoin en Javascript. Cette dernière question m’intéresse le plus, car après avoir utilisé React Native pendant un certain temps, j’ai appris que la façon dont j’écrivais Javascript était un peu dépassée. Jetez un oeil à comment Vous n'avez peut-être pas besoin de JQuery répertorie les fonctionnalités et compare l'utilisation de jQuery à without. Dans certains cas, en utilisant le Version ES6 est plus court et plus rapide que jQuery.

Intéressant aussi que dans certains cas jQuery ne figure même pas dans une liste de cadres actuels.

Conclusion, pour l'instant

Dans le schéma général des choses, si une bibliothèque est disponible pour l'utiliser, alors pourquoi ne pas l'utiliser? Dans Joomla, jQuery est disponible mais n'est pas chargé par défaut. Vous devriez donc l'appeler dans votre module, modèle, etc en utilisant:

HTMLHelper::_('jquery.framework');

Cela dépend également de ce à quoi votre projet est destiné. Nous devrions tous être conscients de la vitesse, en particulier pour le site de commerce électronique, et des problèmes plus importants tels que la quantité d'énergie nécessaire pour faire fonctionner notre site Web. Des options plus écologiques pourraient examiner les performances du site Web pour réduire son empreinte carbone, par exemple.

La technologie évolue au fil du temps, c’est donc une bonne idée de suivre ce qui se passe dans le monde des scripts, car les commandes que vous utilisez toujours peuvent encore fonctionner, mais il peut y avoir de meilleures options.