Avantages de l'utilisation de JavaScript pur sur JQuery

Question

Quels sont les avantages de l'utilisation de Javascript uniquement par rapport à l'utilisation de JQuery uniquement?

J'ai une expérience limitée avec le codage JavaScript et JQuery. J'ai ajouté des bits et des extraits de chacun aux pages HTML, mais j'ai principalement codé des éléments côté serveur dans d'autres langues. J'ai remarqué que si vous pouvez théoriquement faire les mêmes choses en utilisant l'une des deux approches (et bien sûr vous pouvez même les mélanger dans le même projet), il semble y avoir une tendance à toujours commencer à utiliser JQuery dès le début quelles que soient les exigences du projet.

Je me demande donc simplement, y a-t-il des avantages ponctuels à ne pas utiliser JQuery uniquement, mais à utiliser simplement du JavaScript ancien?

Je sais que cela ressemble à une non-question car on peut dire à ce sujet "qu'il n'y a pas de réponse définitive" ou "cela peut être débattu pour toujours", mais j'espère en fait des réponses ponctuelles telles que "vous pouvez le faire en une approche et vous ne pouvez pas le faire avec l'autre ".

Selon le commentaire de scrwtp, je ne me réfère pas seulement à la partie de gestion DOM. Ma question est plutôt: JQuery est une bibliothèque. Pour Javascript. Ce que je trouve étrange à propos de cette bibliothèque par rapport à d'autres bibliothèques pour d'autres langues, c'est que dans le cas de JQyery, elle semble être conçue pour pouvoir l'utiliser exclusivement et ne pas avoir besoin de toucher Javascript directement. C'est par opposition à disons Hibernate et SQL, où même si la bibliothèque (ou plutôt le framework dans ce cas, mais je pense que l'analogie s'applique toujours) prend la poignée sur BEAUCOUP d'aspects, vous pouvez toujours utiliser SQL lorsque vous l'utilisez , au moins pour certains cas marginaux. Cependant, dans le cas JQuery & Javascript, vous pouvez faire tout ce que vous faites avec Javascript en utilisant uniquement JQuery (ou du moins c'est ce qu'il me semble).

Selon le commentaire de Stargazer712: oui, je suis d'accord avec vous, la question ici est, comme vous le dites "juste une question de savoir comment vous allez utiliser JavaScript". C'est ce que j'essayais vraiment de demander, mais j'ai fait de mauvaises formulations. Voici une autre analogie: Spring Expression Language . C'est une bibliothèque Java. Vous ne pouvez pas l'utiliser sans Java, elle est basée sur Java, et tout au long de cela, vous pouvez toujours utiliser Java. Mais dans la pratique, vous pouvez ajouter ceci bibliothèque dans un projet Java, puis écrivez tout votre code en utilisant le langage d'expression de Spring EL qui rend effectivement votre code ne pas ressembler à Java du tout, et c'est même un paradigme déplacement (par exemple, vous n'avez plus d'application de type forte lorsque vous utilisez cela.) Bien que je comprenne que JQuery est juste une bibliothèque JS, il me semble qu'en pratique, cela a le même effet que Spring EL avec Java, c'est-à-dire que vous pouvez utilisez uniquement ses API tout au long d'un projet et évitez les API JavaScript. Et je me demandais si c'était une bonne chose à faire, quels pourraient être les pièges, etc.

(et oui, après avoir lu les réponses de tout le monde, je comprends que:

une. ma question est quelque peu absurde jusqu'à un certain point

b. même si la question était parfaitement exacte, la réponse serait à peu près "non, vous ne pouvez pas utiliser JQuery uniquement tout le temps")

Jesse · Accepted Answer

Tout d'abord - il est impossible d'utiliser jQuery uniquement, tout ce que jQuery fait est d'ajouter un objet $ à votre portée globale, avec un tas de méthodes. Des bibliothèques encore plus manipulatrices comme le prototype ne sont pas une alternative au javascript, elles sont une ceinture d'outils pour résoudre les problèmes courants.

Les principaux avantages de l'ajout de jQuery à votre ceinture d'outils seraient:

compatibilité du navigateur - faire quelque chose comme .attr () est beaucoup plus facile que les alternatives natives, et ne traversera pas les navigateurs.
simplification des opérations généralement compliquées - si vous souhaitez voir une version bien écrite compatible avec un navigateur d'une méthode XHR, jetez un œil à la source de $ .ajax - pour cette seule méthode, cela vaut presque la surcharge de jQ.
Sélection DOM - des choses simples comme la liaison d'événements et la sélection d'éléments DOM peuvent être compliquées et varier selon le navigateur. Sans beaucoup de connaissances, ils peuvent également être facilement écrits de manière médiocre et ralentir votre page.
Accès aux fonctionnalités futures - des choses comme .indexOf et .bind sont du javascript natif, mais pas encore pris en charge par de nombreux navigateurs. Cependant, l'utilisation des versions jQuery de ces méthodes vous permettra de les prendre en charge sur plusieurs navigateurs.

Javascript n'est plus seulement un langage côté client, et parce que jQuery dépend tellement du DOM, c'est un terrible candidat pour passer au serveur. Je recommande fortement de mettre un peu de temps à comprendre pourquoi vous utilisez jQuery (poser cette question est une excellente première étape!), Et à évaluer quand cela est nécessaire. jQuery peut être dangereux, quelques-uns des principaux dangers sont:

qualité du code - jQuery a une communauté énorme et une faible courbe d'apprentissage. C'est une tempête parfaite pour de nombreux plugins open source mal écrits.
inefficacité - jQuery est facile à écrire de manière inefficace. Par exemple, l'utilisation de jQuery au lieu de boucles for n'est pas nécessaire et pourrait avoir un impact sur les performances dans certains cas. Beaucoup de bonnes informations sur ce genre de choses sur JSPerf
bloat - jQuery est une immense bibliothèque. La plupart du temps, vous utiliserez un petit sous-ensemble de ses fonctionnalités et récupérerez toute la bibliothèque. Il existe d'excellentes alternatives qui vous donneront des sous-ensembles de fonctionnalités, comme zepto.js et underscore.js - selon votre situation, vous pouvez économiser quelques octets en choisissant la bonne bibliothèque pour vos besoins.

En fin de compte, jQuery est une bibliothèque incroyablement utile et utile, lorsqu'elle est utilisée correctement. Cependant, ce n'est pas une alternative au javascript. C'est une bibliothèque, tout comme zepto.js , YUI , Dojo , MooTools , et Prototype - dont l'un peut être un bien meilleur choix pour votre projet actuel.

Javascript est un langage mal compris, et n'est récemment considéré comme quelque chose de plus qu'un langage de script par la plupart des gens. Je recommande vraiment de le lire davantage, voici quelques bons endroits pour commencer:

Edit 07/2014 - J'ai remarqué que ce post retient toujours l'attention, j'ai donc ajouté un tas de liens. Ce ne sont pas dans un ordre particulier, mais devraient être utiles.

blog de Ben Alman - plein de bonnes pratiques ici. Je ne suis pas d'accord avec tous, mais j'apprends tout le temps de nouvelles choses sur son blog.
Code Academy - formation de base en javascript et jQuery. Parfois, revenir à l'essentiel aide.
Javascript Garden - un article concernant les fonctionnalités les plus délicates ou mal comprises de javascript. Veuillez lire ceci de temps en temps, jusqu'à ce que tout ait un sens.
Bocoup - ce sont des cours de formation. Si vous en êtes près, allez-y. Beaucoup des meilleurs conférenciers et enseignants JS enseignent cela.
le blog de Paul Irish - pas strictement JS, mais de nombreuses bonnes pratiques sont écrites ici. Les flux Twitter de lui et de Ben sont tous deux formidables à suivre.
Javascript: The Good Parts - souvent appelé "la Bible Javascript", ce livre de Douglas Crockford est un endroit incroyable pour commencer à comprendre le javascript.
Blog d'Isaac Schlueter - Isaac est le créateur de npm, et travaille sur le noyau du nœud. Il écrit beaucoup sur la communauté javascript plutôt que sur les conventions de code, mais si vous entrez vraiment dans js, c'est une bonne lecture.
Javascript de Douglas Crockford - Si Brendan Eich est le père de javascript, Douglas est l'oncle franc de javascript. Il est l'auteur de la spécification JSON, de la bible javascript et de nombreux articles incroyables sur les caprices de javascript et la montée fulgurante.
Blog de Brendan Eich - Brendan est le créateur de javascript - il écrit sur toutes sortes de choses stupides sur son blog, et bien qu'il ait ses défauts en tant que personne, ses messages javascript sont précieux.
Blog de James Halliday (@substack) - Substack est sans doute le développeur node.js le plus important de la communauté - avec environ 400 modules npm (et en croissance chaque jour) et une philosophie directrice de minuscule, semblable à unix modules, tout ce qu'il écrit mérite d'être lu.
Blog de Max Ogden Max Ogden est un autre auteur prolifique de node.js, et est excellent pour écrire des articles de blog qui vous apprennent quelque chose. Il est également l'auteur (avec d'autres je crois) de javascript pour les chats.
Javascript for Cats - Ceci est un court tutoriel qui vous emmène à travers les bases du javascript du point de vue d'un chat. Si vous êtes débutant, lisez-le. C'est amusant et enseigne en une heure ce que de nombreux livres mettent des semaines à communiquer.
Blog de Nicholas Zakas Nicholas est l'auteur de quelques livres javascript fantastiques: Programmation orientée objet en Javascript , Javascript maintenable , Professionnel Javascript pour les développeurs Web , et Javascript haute performance . Il se concentre principalement sur le client, mais a une tonne de meilleures pratiques et de conseils de performance.
Blog de Guillermo Rauch - Guillermo est un autre développeur node.js prolifique, principalement connu pour Socket.io et Mongoose. Son blog (et son nouveau livre, Smashing Node.js sont tous deux d'excellentes ressources.

Je suis sûr qu'il y a beaucoup d'autres ressources formidables auxquelles je ne pense pas ou que je ne connais pas, d'autres répondeurs devraient se sentir libres d'ajouter à cette liste.

Yam Marcovic · Answer

Il y a des avantages, mais on peut se demander s'ils l'emportent vraiment sur les inconvénients.

Le principal est que vous économisez de la bande passante et obtenez des réponses plus rapides. jQuery ajoute un autre ~ 30 Ko à votre réponse. Sur certains réseaux (et dans certains pays), cela pourrait signifier quelques millisecondes supplémentaires. D'un autre côté, cependant, vous pouvez configurer la mise en cache pour cela assez facilement en utilisant votre serveur Web (ou, comme l'a dit Xion, utilisez-le depuis le site de Google pour qu'il n'affecte pas le vôtre et qu'il soit toujours mis en cache).

La deuxième chose est que vous n'aurez peut-être besoin que de fonctionnalités très simples, et que le téléchargement et la configuration de jQuery peuvent prendre plus de temps que la simple mise en œuvre de ce dont vous avez besoin.

Et enfin, vous voudrez peut-être déployer votre propre cadre, ce qui est surtout une mauvaise idée, mais certaines personnes ont leurs raisons.

Si toutefois vous jetez jQuery simplement parce que vous êtes intimidé par la courbe d'apprentissage, alors vous devriez reconsidérer. D'autant plus que c'est plutôt doux.

Spoike · Answer

Autant que je sache, il n'y a vraiment que deux avantages de l'utilisation de Vanilla javascript par rapport à une bibliothèque telle que JQuery , MooTools , etc.

Les bibliothèques ont une charge utile qui consomme de la bande passante. Mais comme les gens l'ont déjà souligné dans les autres réponses, vous pouvez limiter cela avec le gzipping et la mise en cache. Si vous ne voulez qu'un sous-ensemble de jQuery, vous pouvez le faire avec SizzleJS et avec MooTools, vous avez la possibilité de sélectionner les ensembles de fonctionnalités que vous voulez de la même manière que quoi - Modernizr le fait .
Les bibliothèques sont grandes et prennent du temps à apprendre. Là encore, il s'agit d'un investissement ponctuel pour les développeurs ... et il semble agréable sur votre CV de connaître les bibliothèques javascript.
(BONUS) Les bibliothèques ne sont pas un puce argentée donc si vous aimez réinventer la roue, c'est définitivement le chemin à parcourir.

Il convient de souligner pourquoi vous souhaitez utiliser une bibliothèque javascript, pour laquelle il existe de nombreuses:

Vous n'avez pas besoin d'écrire votre propre framework pour soutenir votre développement. Si vous êtes curieux de savoir comment les choses fonctionnent, vous pouvez consulter le code car il est open source.
Les bibliothèques résolvent la compatibilité du navigateur. DOM et javascript présentent des différences entre les navigateurs. Croyez-moi, c'est un énorme puits de temps si vous devez pirater vous-même les correctifs.
Il est de facto standard d'Internet d'utiliser des bibliothèques javascript, la plupart d'entre elles sont bien documentées et la plupart des développeurs web (qui connaissent javascript) savent comment les utiliser.
Vous n'abandonnez pas vraiment javascript lorsque vous utilisez une bibliothèque. Vous devez toujours connaître Javascript avec ses types, ses objets, comment fermetures fonctionnent, etc.
La plupart des bibliothèques sont modularisées et il ne faut pas longtemps pour écrire des plugins ou utiliser nécessite et le modèle AMD .
La sélection d'éléments CSS dans le DOM est d'une grande aide.
(BONUS) Vous pouvez également les utiliser avec CoffeeScript .

J'avais l'habitude de travailler dans une boutique en ligne qui était résolue à utiliser le javascript Vanilla parce que jQuery était grand et effrayant. Cette décision, principalement influencée par un seul "développeur javascript", a été la source de nombreux bogues de navigateur et d'un développement lent et essayer d'entrer dans sa base de code a été une expérience époustouflante. Écrire votre propre framework peut sembler être une bonne idée, mais si vous voulez embaucher de nouveaux développeurs, ils ne peuvent pas rapidement entrer et aider. Ensuite, il y a aussi la question du facteur de bus à considérer.

Comme je l'ai dit, j'y travaillais ... il y avait des pâturages plus verts ailleurs. : ^)

Ryan · Answer

Il se trouve que je mélange un peu l'utilisation des deux. La principale raison en est que pour certaines applications (pensez aux extensions chrome), vous n'avez pas besoin de la prise en charge de plusieurs navigateurs. Ce qui signifie que je peux profiter de nouvelles avancées comme css3 qui, avec des choses comme les transitions, peuvent simplifier votre code d'une tonne par rapport à l'utilisation de jquery.

Aussi, je fais souvent quelque chose de personnalisé. Comme tous les autres l'ont dit, vous ne devriez pas réinventer la roue. Mais quand on vous demande de faire des fonctionnalités folles, je trouve souvent qu'il est beaucoup plus facile de l'écrire moi-même, puis d'essayer de pirater un plugin jquery qui est proche mais pas une correspondance parfaite.

J'ai également travaillé avec des développeurs qui ne travaillent qu'avec jquery. Et je dois dire qu'ils ont compromis la fonctionnalité beaucoup plus souvent que s'ils ne pouvaient pas trouver un plugin jquery qui a fait ce qu'ils voulaient.

À un moment donné du développement Web, il vous sera demandé de faire quelque chose qui n'est pas pré-emballé dans une bibliothèque. Donc, à ce stade, vous feriez mieux de vous assurer de comprendre comment fonctionne réellement le langage de base.

Donc TLDC: Utilisez les deux, vous êtes désavantagé en utilisant uniquement Vanilla et vous êtes désavantagé si vous ne connaissez pas Vanilla à l'intérieur et à l'extérieur et insistez pour toujours utiliser jquery.

Mike Partridge · Answer

La seule chose à laquelle je peux penser que vous ne pouvez pas faire sans JQuery serait d'utiliser des plugins JQuery; même alors, vous pourriez écrire votre propre bibliothèque JS qui fournirait exactement ce dont le plugin a besoin.

Pensez-y comme ceci: JQuery est une bibliothèque Javascript open-source écrite en Javascript; vous pouvez regarder la source et ainsi apprendre à faire tout ce qu'elle fait.

Vous ne pouvez pas utiliser JQuery sans utiliser du vieux Javascript. Vous n'utiliserez probablement pas document.getElementById, mais vous définirez toujours les fonctions et les variables de la manière Javascript standard; vous pourriez même écrire une boucle for standard.

Le principal avantage de l'utilisation de JQuery est à peu près le même que n'importe quelle autre bibliothèque tierce dans n'importe quel langage: vous n'aurez pas à écrire autant de code pour implémenter la logique spécifique à votre application.

Ne laissez pas la taille vous effrayer. version CDN est un téléchargement de ~ 33k qui sera mis en cache par le navigateur de l'utilisateur après le premier coup de page.

Jan Prieser · Answer

Si vous êtes inquiet au sujet des performances, vous devriez essayer d'utiliser Vanilla js chaque fois que possible. les frameworks ajoutent non seulement une surcharge de bande passante, mais également une surcharge de traitement. Et jQuery est également compatible avec les navigateurs assez anciens.

si vous travaillez sur des applications mobiles ou des jeux (ou les deux combinés), vous avez d'abord besoin de performances et d'efficacité des ressources.

jQuery et les plugins peuvent accélérer votre développement, mais surtout si vous comptez sur des plugins jquery tiers, vous devez savoir ce qu'ils font à l'intérieur. Beaucoup d'entre eux sont de mauvais exemples de qualité et d'efficacité du code.

jQuery peut être 2 à 10 fois plus lent que JavaScript natif. Et cela peut facilement encourager les développeurs à ne pas concevoir correctement leur interface et à trop compter sur les sélecteurs jQuery qui sont beaucoup plus lents que natifs.