En ce qui concerne jQuery, beaucoup de gens disent: «Utilisez simplement du JavaScript normal. Vous n'avez pas besoin d'une bibliothèque jQuery. " Que puis-je dire? Je n'ai pas besoin de beaucoup de choses, mais malgré cela, c'est bien quand elles le sont. Tout comme jQuery. Je n'ai pas besoin de cette bibliothèque, mais c'est vraiment agréable de l'avoir à portée de main.
Des sites comme
Vous n'avez peut-être pas besoin de jQuery (YMNJQ) font la promotion de l'idée que jQuery est très facile à éliminer. Mais le tout premier exemple sur ce site démontre une bonne raison d'utiliser jQuery. Là, une simple ligne de code jQuery est remplacée par 10 lignes de JS standard!
La plupart des API JavaScript, en particulier celles qui se concentrent sur l'utilisation du DOM, offensent mes sens esthétiques. C'est, pour le moins, mon attitude envers eux. Pour parler directement, je pense que ces API sont un véritable cauchemar. Par exemple, la construction
el.insertAdjacentElement('afterend', other) fonctionne certainement. Mais beaucoup plus joli regarde
$(el).after(other) . Bien que je n'aie jamais vraiment aimé l'apparence de la fonction
$() , elle est incomparablement meilleure que ce que les API standard pour travailler avec le DOM nous donnent. Je sais qu'au lieu de
$() vous pouvez utiliser quelque chose comme
jQuery(sel) ou
window.jq = jQuery . Mais je ne programme pas dans un espace sans air. Par conséquent, je préfère utiliser des techniques standard. Je ne sais pas si c'est bon ou mauvais, mais la norme pour utiliser jQuery est la construction
$() .
Essayez de vous rappeler rapidement comment obtenir un élément voisin d'un autre élément à l'aide du DOM. Que dois-je utiliser pour cela -
nextSibling ou
nextElementSibling ? Quelle est la différence? Et quels navigateurs prennent en charge telle ou telle méthode? Pendant que vous essayez de vous en souvenir et de regarder le MDN, en vous vérifiant, moi, en utilisant jQuery, il suffit d'écrire
next() ou
prev() .
Il n'est pas pratique d'effectuer de nombreuses opérations courantes implémentées dans l'API JavaScript. Je pourrais donner ici une liste complète de telles opérations, mais pour moi, cela a été parfaitement fait sur la page YMNJQ.
Pour résoudre divers problèmes simples à l'aide des outils JS, des fonctions auxiliaires sont nécessaires. Et sur le site du YMNJQ, encore une fois, vous pouvez trouver de nombreux exemples. L'utilisation de jQuery est un moyen standard d'inclure de telles fonctions d'assistance dans votre code de projet. Dans le même temps, le programmeur n'a pas besoin chaque fois qu'il a besoin de quelque chose comme ça pour récupérer des morceaux de code des premières réponses à Stack Overflow qui se sont présentées sur son bras.
Bien que les problèmes de compatibilité du navigateur aient perdu de leur gravité ces jours-ci, ils sont toujours d'actualité. Surtout - pour ceux qui n'appartiennent pas au camp des développeurs qui croient que si quelque chose fonctionne dans 85% des navigateurs, cela leur convient. Soit dit en passant,
voici la documentation expliquant pourquoi Hello CSS n'utilise pas de variables CSS.
Dois-je toujours utiliser jQuery? Non, bien sûr que non. Toute dépendance supplémentaire est une augmentation de la complexité du projet et une augmentation du volume de son code. Mais jQuery n'est pas une grande bibliothèque. L'ensemble standard, minifié et compressé, prend 30 Kb. L'assemblage personnalisé sans ajax et les fonctionnalités rarement utilisées est de 23 Ko. Et l'assembly, qui utilise
querySelector au lieu de
querySelector , ne prend que 17 Ko. Pour résoudre de nombreux problèmes, je suis assez satisfait de l'assemblage standard de 30 Kb et de l'assemblage optimisé de 17 Kb.
Ici, vous pouvez voir combien d'efforts ont été déployés pour supprimer jQuery de Bootstrap et passer à JS normal.
Les développeurs ont écrit leurs propres fonctions d'assistance. Ils ont dû abandonner le support d'IE, car ce support était très difficile à mettre en œuvre. Ils ont rendu l'API incompatible ("nous avons tout cassé") et ont passé un an et demi sur tout cela. Je ne peux pas dire que ce qui s’est passé est bien meilleur que ce qui s’est passé.
Je comprends les raisons de traduire Bootstrap en JS standard. Par exemple, les développeurs souhaitent utiliser Bootstrap avec Vue.js, ou quelque chose de similaire. Et Vue.js et jQuery dans un projet est déjà un peu un buste. Je suis un grand partisan de la réduction de la quantité de code inutile sur le Web (et
voici quelques documents à ce sujet). Mais ici, je propose d'examiner la situation d'un point de vue pragmatique et réaliste. L'inclusion de 17 Ko de code jQuery dans Bootstrap est-elle si mauvaise? Lorsque je dis que pour afficher des sites comme le Medium ou le New York Times, vous devez télécharger plus d'un mégaoctet de code JavaScript, afin de protéger cette situation, ils me demandent si je suis assis sur une ligne de modem de 56 kilobits. Megabyte JS est très bien. 17Kb jQuery est-il vraiment lourd?
Il y a de bonnes raisons de ne pas utiliser jQuery. Par exemple, jQuery n'est pas nécessaire si vous écrivez du code que vous souhaitez partager avec d'autres, ou si vous créez une petite fonction. Mais pourquoi se retourner pour ne pas utiliser jQuery? Pourquoi tout cet effort si vous pouvez simplement écrire
$() ? Je ne pense pas que jQuery devrait être utilisé partout et toujours, mais je ne pense pas que le rejet fanatique de jQuery soit juste.
Je veux noter que je ne suis pas marié à jQuery. Je serai heureux d'utiliser quelque chose comme "jQuery light" - une sorte de bibliothèque qui couvre les lacunes des API standard, donnant au programmeur quelque chose de plus agréable. Le site YMNJQ recommande, entre autres, les
bibliothèques bonzo et
$ dom , conçues pour résoudre divers problèmes. Mais bon nombre d'entre eux, semble-t-il, n'ont pas été soutenus depuis longtemps. De plus, beaucoup connaissent déjà jQuery. Pourquoi changer jQuery pour autre chose sans raison valable?
De nombreux lecteurs peuvent se demander ce que moi, dans le contexte de ce document, je peux dire à propos de Vue.js, React et d'autres cadres modernes. Mais le but de cet article est de mapper du JavaScript et du jQuery simples, plutôt que d'offrir à la communauté une «théorie grandiose générale du développement du frontend».
Compte tenu de ce qui précède, je pense que je peux trouver très peu de raisons d'utiliser JS standard où vous pouvez utiliser jQuery. Cela est principalement dû au fait que je veux créer des pages rapides et utiliser les constructions de travail les plus simples. En même temps, je m'efforce de faire en sorte que le plus possible d'utilisateurs du Web puissent consulter mes pages. L'expérience me dit que le moyen le plus court pour atteindre cet objectif sont les modèles générés sur le serveur, qui sont légèrement assaisonnés avec JavaScript dans le style de "l'amélioration progressive". Si vous comparez de tels projets avec quelque chose qui utilise quelque chose de plus complexe, il s'avère qu'ils sont souvent plus faciles à développer. De tels projets sont généralement plus rapides, ils ont généralement moins d'erreurs et, tout en y travaillant, le ventilateur de l'ordinateur portable ne fait pas de bruit qui peut réveiller toute la maison.
Est-ce à dire que les frameworks web modernes et les bibliothèques puissantes sont toujours mauvais? Non, non. Très peu mérite d'être toujours appelé mauvais ou bon. Mais utiliser le framework signifie faire des compromis (cela est bien sûr vrai pour jQuery).
En général, je vois le Web comme un environnement de visualisation de documents, et non comme un système d'exploitation. Et «l'approche documentaire» est bonne non seulement pour les sites réguliers, mais aussi pour de nombreuses «applications Web» (peu importe comment vous l'appelez).
Chers lecteurs! Utilisez-vous jQuery?
