Avantages de l'utilisation de JavaScript pur sur JQuery

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

J'ai peu d'expérience avec JavaScript et le codage JQuery. J'ai ajouté des bits et des extraits de chaque mot à des 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. peu importe les exigences du projet.

Je me demande donc simplement s'il existe des avantages ponctuels à ne pas utiliser JQuery uniquement, mais simplement à utiliser du vieux et simple JavaScript.

Je sais que cela ressemble à une question non posée car on peut dire à ce sujet qu’il n’ya "pas de réponse définitive" ou "on peut en débattre à jamais", mais j’espère réellement des réponses ponctuelles telles que "Vous pouvez le faire en une approche et vous ne pouvez pas le faire avec l'autre ".

En tant que commentaire de scrwtp, je ne fais pas référence uniquement à la partie DOM Handling. Ma question est plutôt: JQuery est une bibliothèque. Pour Javascript. Ce que je trouve étrange à propos de cette bibliothèque par opposition à d’autres bibliothèques pour d’autres langues, c’est que dans le cas de JQyery, elle semble être conçue pour pouvoir être utilisée exclusivement et ne nécessite pas de toucher Javascript directement. Ceci est opposé à, disons, Hibernate et SQL, où même si la bibliothèque (ou plutôt le cadre dans ce cas, mais je pense que l'analogie est toujours valable) prend le contrôle de BEAUCOUP d'aspects, vous pouvez toujours utiliser SQL quand vous l'utilisez , du moins pour certains cas marginaux. Cependant, dans le cas de JQuery & Javascript, vous pouvez faire tout ce que vous faites avec Javascript en utilisant uniquement JQuery (ou du moins c'est ce que cela me semble).

Selon le commentaire de Stargazer712: oui, je suis d'accord avec vous, la question qui se pose est, comme vous le dites, "juste une question de savoir comment vous allez utiliser JavaScript". C’est ce que je souhaitais réellement demander, mais j’ai formulé de mauvaises formulations. Voici une autre analogie: Spring Expression Language. C'est une librairie Java. Vous ne pouvez pas l'utiliser sans Java, il est basé sur Java et vous avez toujours besoin d'utiliser Java. Mais en pratique, vous pouvez ajouter cette bibliothèque à un projet Java, puis écrire tout votre code en utilisant le langage d’expression de Spring EL, qui rendra votre code totalement différent de Java, et même un changement de paradigme (par exemple, vous n’avez plus application de type forte lors de l'utilisation de cette application). Bien que je comprenne que JQuery n’est qu’une bibliothèque JS, il me semble qu’en pratique, il a le même effet que Spring EL avec Java, c’est-à-dire que vous ne pouvez utiliser ses API que dans un projet et éviter 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 un peu non sensuelle jusqu'à un certain point

b. même si la question était parfaitement exacte, la réponse à cette question serait plutôt "non, vous ne pouvez pas utiliser JQuery uniquement à tout moment)

Tout d'abord, il est impossible d'utiliser jQuery uniquement. Tout ce que jQuery fait, c'est ajouter un objet $ à votre portée globale, avec un tas de méthodes. Même des bibliothèques plus manipulables, telles que prototype, ne sont pas une alternative au javascript, elles constituent une panoplie d'outils pour résoudre les problèmes courants.

L'ajout de jQuery à votre toolbelt présenterait les principaux avantages suivants:

• Compatibilité de 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 le navigateur, d'une méthode XHR, jetez un oeil à la source de $ .ajax - cette méthode seule vaut presque le surcoût 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 différer d'un navigateur à l'autre. Sans beaucoup de connaissances, ils peuvent également être mal écrits et ralentir votre page.
• Accès aux futures fonctionnalités - des éléments tels que .indexOf et .bind sont en JavaScript, mais ne sont pas encore pris en charge par de nombreux navigateurs. Cependant, l’utilisation des versions jQuery de ces méthodes vous permettra de les supporter d’un navigateur à l’autre.

Javascript n'est plus seulement un langage côté client, et comme jQuery est tellement dépendant du DOM, il est extrêmement difficile de passer au serveur. Je recommande fortement de prévoir un peu de temps pour comprendre pourquoi vous utilisez jQuery (poser cette question est une excellente première étape!) Et d’évaluer quand cela est nécessaire. jQuery peut être dangereux, voici quelques-uns des principaux dangers:

• qualité du code - jQuery a une énorme communauté et une courbe d'apprentissage faible. C'est une tempête parfaite pour beaucoup de plugins open source mal écrits.
• inefficacité - jQuery est facile à écrire de manière inefficace. Par exemple, l'utilisation de boucles jQuery au lieu de pour les boucles for est inutile et peut avoir un impact sur les performances dans certains cas. Beaucoup d’informations intéressantes sur ce sujet chez 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. Certaines alternatives intéressantes vous donneront des sous-ensembles de fonctionnalités, telles que zepto.js et underscore.js. Selon votre situation, vous pouvez économiser des octets en choisissant la bonne bibliothèque pour vos besoins.

En fin de compte, jQuery est une bibliothèque incroyablement 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 - l'une d'elles peut constituer un bien meilleur choix pour votre projet actuel.

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

Edit 07/2014 - J'ai remarqué que ce message retient toujours l'attention, alors j'ai ajouté de nombreux liens. Ce ne sont dans aucun ordre particulier, mais devraient être utiles.

• Le blog de Ben Alman - plein de bonnes pratiques ici. Je ne suis pas d'accord avec tous, mais j'apprends constamment de nouvelles choses sur son blog.
• Code Academy - formation de base sur javascript et jQuery. Parfois, le retour aux sources peut aider.
• Javascript Garden - un article concernant les fonctionnalités les plus délicates ou mal comprises du javascript. Veuillez lire ceci de temps en temps, jusqu'à ce que tout ait du sens.
• Bocoup - ce sont des cours de formation. Si vous en êtes près, allez-y. Beaucoup des meilleurs orateurs et professeurs de JS enseignent ces cours.
• Le blog de Paul Irish - pas strictement JS, mais de nombreuses pratiques exemplaires sont décrites ici. Les flux Twitter de Ben et de lui sont excellents à suivre.
• Javascript: The Good Parts - souvent appelé "La Bible Javascript", ce livre de Douglas Crockford est un endroit fantastique pour commencer à comprendre le javascript.
• Blog d'Isaac Schlueter - Isaac est le créateur de npm et travaille sur le noyau. Il écrit beaucoup sur la communauté javascript plutôt que sur les conventions de code, mais si vous obtenez vraiment js, c'est une excellente lecture.
• Le code Javascript de Douglas Crockford - Si Brendan Eich est le père de javascript, Douglas est son oncle franc. Il est l'auteur de la spécification JSON, de la bible javascript et de nombreux messages étonnants sur les bizarreries et la montée en puissance de javascript.
• Le blog de Brendan Eich - Brendan est le créateur de javascript - il écrit sur toutes sortes de choses stupides sur son blog, et même s'il a ses défauts en tant que personne, ses publications en javascript sont précieuses.
• Le blog de James Halliday (@substack) - Substack est sans doute le développeur de node.js le plus important de la communauté - avec environ 400 modules npm (et de plus en plus nombreux) et une philosophie de base de modules minuscules de type Unix, tout ce qu'il écrit vaut la peine en train de lire.
• Blog de Max Ogden Max Ogden est un autre auteur prolifique de node.js. Il écrit très bien 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 pour les chats - Ceci est un court tutoriel qui vous explique les bases du javascript du point de vue d'un chat. Si vous êtes débutant, lisez ceci. 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 fantastiques javascript: la programmation orientée objet en Javascript , maintenable Javascript , Javascript professionnel pour les développeurs Web et haute performance Javascript . Il se concentre principalement sur le client, mais a une tonne de meilleures pratiques et de conseils en matière de performance.
• Blog de Guillermo Rauch - Guillermo est un autre développeur prolifique de node.js, principalement connu pour Socket.io et Mongoose. Son blog (et son nouveau livre, Smashing Node.js sont d'excellentes ressources.

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

Il y a des avantages, mais on peut se demander s'ils compensent réellement les inconvénients.

Le principal consiste à économiser de la bande passante et à obtenir des réponses plus rapides. jQuery ajoute environ 30 Ko à votre réponse. Sur certains réseaux (et dans certains pays), cela pourrait signifier quelques millisecondes de plus. Par contre, vous pouvez configurer la mise en cache assez facilement à l’aide de votre serveur Web (ou comme Xion l’a dit, utilisez-la à partir du site de Google pour ne pas avoir d’impact sur votre propre, et restez néanmoins en cache).

La deuxième chose à faire est que vous n’auriez besoin que de fonctionnalités très simples. Seul le téléchargement et l’installation de jQuery prendrait plus de temps que la simple implémentation de ce dont vous avez besoin.

Enfin, vous voudrez peut-être lancer votre propre cadre, ce qui est généralement une mauvaise idée, mais certaines personnes ont leurs raisons.

Si toutefois vous vous débarrassez de jQuery simplement parce que vous êtes intimidé par la courbe d'apprentissage, vous devriez alors reconsidérer votre décision. Surtout que c'est plutôt doux.

Autant que je sache, l' utilisation de javascript dans la version vanille ne présente en réalité que deux avantages 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 gzipping et la mise en cache. Si vous voulez seulement un sous-ensemble de jQuery, vous pouvez le faire avec SizzleJS et avec MooTools, vous avez la possibilité de sélectionner les jeux de fonctionnalités souhaités de la même manière que ce que Modernizr fait .
• Les bibliothèques sont grandes et prennent du temps à apprendre. Encore une fois, il s’agit d’un investissement ponctuel pour les développeurs ... et les CV javascript ont belle allure.
• (BONUS) Les bibliothèques ne sont pas une solution miracle, donc si vous aimez réinventer la roue, c’est vraiment la voie à suivre.

Il est utile de préciser pourquoi vous souhaitez utiliser une bibliothèque javascript, pour laquelle il existe de nombreuses ressources:

• Vous n'avez pas besoin d'écrire votre propre framework pour supporter 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, ceci est un énorme gouffre temporel si vous devez réparer vous-même.
• Il est de facto standard Internet d’utiliser des bibliothèques javascript, la plupart d’entre elles sont maintenant bien documentées et la plupart des développeurs Web (qui connaissent le javascript) savent comment les utiliser.
• Vous n'abandonnez pas vraiment le javascript lorsque vous utilisez une bibliothèque. Vous devez toujours connaître Javascript avec ses types, ses objets, le fonctionnement des fermetures , etc.
• La plupart des librairies sont modularisées et l'écriture de plugins ou d'utilisation requiert peu de temps et le modèle AMD .
• CSS sélectionner des éléments du DOM est une aide énorme.
• (BONUS) Vous pouvez également les utiliser avec CoffeeScript .

Auparavant, je travaillais dans une boutique en ligne qui utilisait javascript à la vanille parce que jQuery était énorme et effrayant. Cette décision, principalement influencée par un "développeur javascript" isolé, a été à l'origine de nombreux bugs de navigateur et de son lent développement, et essayer de pénétrer dans son code a été une expérience époustouflante. Écrire votre propre framework peut sembler une bonne idée, mais si vous souhaitez embaucher de nouveaux développeurs, ils ne peuvent pas intervenir rapidement et vous aider. Il y a aussi la question du facteur bus à prendre en compte.

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

Il m'est arrivé de mélanger un peu l'utilisation des deux. La principale raison à cela 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 tirer parti des nouvelles avancées telles que CSS3 qui, avec des transitions par exemple, peuvent simplifier considérablement votre code par rapport à l’utilisation de jQuery.

De plus, je fais souvent quelque chose de personnalisé. Comme tous les autres l'ont dit, il ne faut pas réinventer la roue. Mais quand on vous demande de faire une fonctionnalité folle, je trouve souvent qu'il est beaucoup plus facile de l'écrire moi-même que d'essayer de pirater un plugin jquery qui est proche mais qui ne correspond pas parfaitement.

J'ai également travaillé avec des développeurs qui ne travaillent qu'avec jquery. Et je dois dire qu'ils ont beaucoup plus souvent fait des compromis sur les fonctionnalités que s'ils ne pouvaient pas trouver un plugin jQuery qui fasse 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 devez vous assurer de bien comprendre le fonctionnement réel du langage de base.

Donc TLDC : Utilisez les deux, vous êtes désavantagé en utilisant simplement la vanille et vous êtes en désavantage si vous ne connaissez pas la vanille de fond en comble et insistez pour toujours utiliser jQuery.

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 apprendre ainsi à faire tout ce que vous faites.

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

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

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

Si les performances vous inquiètent, essayez autant que possible d'utiliser vanilla js . Les frameworks non seulement ajoutent un surcoût en bande passante mais également en traitement. Et jQuery est livré avec une compatibilité de navigateur pour les très vieux navigateurs.

si vous travaillez sur des applications mobiles ou sur des jeux (ou les deux combinés), vous avez besoin d’abord de performance et d’efficacité en termes de 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 le JavaScript natif. Et cela peut facilement encourager les développeurs à ne pas concevoir correctement leur interface et à s’appuyer trop sur les sélecteurs jQuery, qui sont beaucoup plus lents que natifs.