Quelles sont les raisons techniques empiriques de ne pas utiliser jQuery?
Context: Je suis étonné par le nombre de développeurs frontaux qui piratent HTML, Javascript et CSS toute la journée et que ignorer des outils comme jQuery ( ou d'autres frameworks d'assistance équivalents ) et refuser pour les utiliser. Je ne parle pas des gourous JavaScript, je parle dans les tranchées tous les jours des développeurs de production Joe. Je reçois beaucoup d'arguments qui sont plus comme des excuses ou des opinions personnelles que je ne pense pas avoir de mérite technique, je veux m'assurer de ne rien manquer.
Question: Quelles sont les raisons techniques empiriques de ne pas utiliser jQuery?
Je ne cherche pas d'arguments religieux ou dogmatiques ou d'opinions subjectives "comme un autre cadre est meilleur", considérez jQuery l'homme de paille pour tous les cadres comparables dans la question.
Mise à jour 2015:
Dans cette réponse de 2011, je parle de bibliothèques comme jQuery, YUI ou Prototype. Aujourd'hui en 2015, ce raisonnement est toujours applicable à des frameworks comme Angular, React ou Ember. Au cours de ces 4 années, la technologie a énormément progressé et même si je vois beaucoup moins de préjugés contre React ou Angular que j'ai vu contre jQuery ou YUI, le même genre de pensée - quoique dans une moindre mesure - est toujours présent aujourd'hui.
Mise à jour 2016:
Je recommande fortement un article publié il y a quelques jours:
- Pourquoi jQuery? par Michael S. Mikowski, auteur du livre Single Page Web Applications
Cet article est essentiellement une réponse très détaillée à cette même question. Si elle avait été disponible lorsque j'écrivais la réponse ci-dessous, je l'aurais certainement citée.
Réponse originale:
Je répondrai à propos de jQuery mais ce sont les mêmes arguments que j'ai entendus contre l'utilisation de YUI, Prototype, Dojo, Ext et quelques autres. Principaux arguments que j'ai entendus:
taille du fichier , qui est en fait de 84,6 Ko en cas de jQuery 3.2.1 - probablement plus petit que le logo en moyenne site Web et peut être servi à partir du CDN de Google, qui est probablement déjà dans le cache de la plupart de vos visiteurs. Comme utiliser jQuery signifie toujours une taille de fichier plus petite de vos propres fichiers JavaScript, cela peut en fait signifier plus petit télécharger, même s'il n'est pas déjà dans le cache du navigateur.
vitesse - écrire du JavaScript pur peut être plus rapide, mais écrire portable JavaScript semble impossible pour la plupart des gens. Un site Web plus rapide mais qui ne fonctionne pas sur tous les navigateurs populaires est inutile dans le monde réel. De plus, jQuery utilise des optimisations assez lourdes pour être vraiment sacrément rapides et continue à être encore plus rapide avec chaque version, il n'est donc pas si facile d'écrire du code plus rapidement à la main pour autre chose que des exemples triviaux. (*)
"propriété intellectuelle" - une entreprise a peur d'utiliser le code de quelqu'un d'autre - alors qu'en fait jQuery est un logiciel libre et gratuit qui est utilisé partout sur le blog de votre grand-mère à Amazon, de Twitter à Bank of America, de Google à Microsoft - s'ils peuvent l'utiliser, n'importe quelle entreprise peut l'utiliser.
Je ne me souviens pas avoir entendu un autre argument utilisé sérieusement.
(*) Voici un exemple trivial: getElementById ('someid') vs jQuery ('# someid')
L'utilisation de getElementById est-elle plus rapide? Oui. Et bien sûr, tout le monde vérifie toujours le parentNode pour attraper lorsque Blackberry 4.6 renvoie des nœuds qui ne sont plus dans le document, non? jQuery le fait. Et tout le monde gère le cas où IE et Opera renvoie les éléments par leur nom au lieu de l'ID, non? JQuery le fait. Si vous ne le faites pas, votre code n'est pas portable et vous introduisez des bogues subtils qui peuvent être très difficiles à trouver. Et getElementById est l'exemple le plus trivial que l'on puisse trouver - ne me lancez même pas sur les événements et AJAX et le DOM ...
Mettre à jour:
Il y a en fait un quatrième résultat de demander pourquoi quelqu'un ne veut pas utiliser jQuery. J'ai oublié de le mettre sur cette liste car ce n'est pas vraiment une réponse mais plutôt le manque de toute réponse. Le commentaire que j'ai reçu hier me l'a rappelé. Ce n'est guère une "raison technique" à ajouter à la liste, mais elle peut néanmoins être intéressante et peut être en fait la réaction la plus courante.
Ce que je soupçonne personnellement d'être la principale raison sous-jacente à toutes ces réactions, cependant, est ce que je pense être le plus grand obstacle au progrès de l'informatique : "Je ne veux pas l'utiliser parce que je ne l'ai jamais fait, donc ça ne doit pas être si important."
C'était autrefois la réaction à l'optimisation des assembleurs, des compilateurs, de la programmation structurée, des langages de niveau supérieur, de la récupération de place, de la programmation orientée objet, des fermetures ou à peu près tout ce que nous tenons maintenant pour acquis - et aujourd'hui, c'est AJAX Peut-être qu'un jour, personne ne se souviendra que nous avions l'habitude d'interagir manuellement avec l'API DOM brute au niveau de l'application, comme maintenant personne ne se souvient que nous avions l'habitude d'écrire des programmes en utilisant nombres hexadécimaux bruts, sans fioritures et impénétrables .
jQuery exprime tout dans un paradigme centré sur DOM qui peut être trompeur et ne nécessite pas d'exprimer des choses dans un modèle d'application.
De nombreux développeurs finissent par se programmer dans un coin avec ce modèle centré sur DOM et finissent par réaliser qu'ils n'ont rien créé d'extensible ou de réutilisable.
Rebecca Murphey a une excellente rédaction de son propre passage à Dojo de jQuery - le blog explique plus pourquoi pas jQuery versus pourquoi Dojo.
L'une des raisons de ne pas utiliser de framework - et c'est un cas extrême pour Edge - est lors de l'écriture de code intégrable pour un autre site Web, comme une bannière. L'insertion arbitraire d'une bibliothèque compliquée ou d'une autre polluera l'espace de noms et risque de casser le site de quelqu'un d'autre. Non pas que je ne passerais pas devant certains annonceurs pour essayer de toute façon, l'écume suceuse d'étang, mais je m'égare ...
Je désapprouve l'ajout d'un cadre quand on est déjà présent et tout aussi capable. Je le vois trop souvent et c'est ma haine pour animaux de compagnie, je le vois comme un ballonnement injustifié. C'est une autre question entièrement.
À part cela, je ne peux pas penser à une raison justifiée de ne pas le faire.
taille du fichier - mais vraiment, au-delà de cela, c'est un don absolu pour les différences de javascript et de navigateur multiplateforme. Vous devriez avoir de très bonnes raisons de ne pas le vouloir dans votre boîte à outils (ou être un idiot de développeur fondamentaliste).
- Ils ne peuvent pas justifier la taille du fichier (même si c'est probablement moins que le script qui n'utilise pas les abstractions fournies).
- Ils ne veulent pas compter sur des outils tiers.
- Leur entreprise ne veut exécuter aucune bibliothèque (pour quelque raison que ce soit).
- Leur entreprise ne souhaite pas exécuter de code JavaScript non écrit par leurs employés.
- Learning: Pour réellement coder tout et en savoir plus. (Plutôt que d'utiliser des choses pré-codées)
- Taille: jQuery a des tonnes de fonctionnalités dont vous pourriez ne pas avoir besoin, pourquoi inciter l'utilisateur à télécharger autant de code s'il ne sera pas utilisé?
- Alternatives: à ce stade, il existe des dizaines de cadres Web plus puissants et bien structurés.
- Flexibilité: Bien que jQuery soit vraiment flexible, vous pourriez avoir besoin de quelque chose qu'il ne fournit pas.
Bien sûr, j'aime jQuery, mais il y a quelques raisons de ne pas utiliser jQuery:
- Taille de téléchargement/bande passante: jQuery 1.5 est désormais supérieur à 200K non compressé, pour certains la taille de la bibliothèque est trop pour justifier l'avantage.
- Performances: l'écriture de JS natif sera toujours plus rapide que de l'abstraction derrière une bibliothèque.
- Complexité accrue: de nombreuses personnes téléchargeront l'intégralité de la bibliothèque jQuery alors qu'elles n'en ont vraiment besoin que de quelques fonctionnalités intéressantes.
- Dépendances des applications: l'introduction de dépendances a toujours ses raccords. S'il y a un bogue dans jQuery, vous pouvez déboguer et modifier le fichier, mais la mise à niveau ultérieure pose des problèmes. Vous pouvez laisser le bogue, mais maintenant vous dépendez du calendrier de jQuery pour un correctif, pas le vôtre.
Parce que bien souvent, c'est tout simplement inutile. si tout ce que je veux faire est de valider une entrée ou de mettre en évidence un champ, il est tout aussi facile d'écrire un code javascript/dom simple. Et jQuery n'aide pas vraiment dans des cas aussi simples, donc la question devrait être pourquoi l'utiliser?
De toute évidence, il existe de nombreux cas où il est très utile, mais parfois, les gens semblent l'utiliser également sans raison réelle.
Je préférerais utiliser jquery pour la manipulation de dom ou traverser le dom, ce qui est vraiment facile avec jquery. De plus, attacher un événement ou une délégation d'événement est si facile en utilisant jquery ou un autre framework sinon vous devez écrire une pièce jointe d'événement personnalisée pour IE ou non IE navigateurs, etc.
Mais il a une certaine pénalité de performance lorsque vous utilisez $ .each au lieu de Vanilla JS pour et array.Push () ... d'autres problèmes comme si vous liez un événement et le supprimez sans le délier, il y aura une fuite de mémoire ....
Ma conclusion est d'utiliser uniquement n'importe quel cadre pour la manipulation complexe de dom et d'utiliser le reste Vanilla JS
Pourquoi ne pas utiliser jQuery?
Je ne peux pas penser à une bonne excuse pour utiliser JavaScript Vanilla sur jQuery (à part le facteur d'intimidation d'apprendre quelque chose de nouveau), mais certaines personnes préfèrent d'autres cadres JavaScript (comme l'excellent MooTools ) en raison de la différences philosophiques entre eux.
Certaines personnes n'aiment tout simplement pas la syntaxe de jQuery DSL - ish, mais elles reconnaissent l'importance d'utiliser un cadre JavaScript robuste.
Personnellement, j'aime jQuery , mais je connais des gens qui utilisent d'autres frameworks et qui ne sont pas moins productifs.