Quand utiliser le JavaScript vanille contre jQuery?

j'ai remarqué en surveillant/essayant de répondre aux questions courantes de jQuery, qu'il y a certaines pratiques utilisant javascript, au lieu de jQuery, qui permettent en fait de écrire moins et faire ... eh bien, le même montant. Et peut également produire des avantages de rendement.

un exemple spécifique

$(this) vs this

à L'intérieur d'un événement de clic référençant l'id des objets cliqués

jQuery

$(this).attr("id");

Javascript

this.id;

y a-t-il d'autres pratiques courantes comme celle-ci? Là où certaines opérations Javascript pourraient être effectuées plus facilement, sans introduire jQuery dans le mix. Ou est-ce un cas rare? (d'un "raccourci" nécessitant effectivement plus de code)

EDIT : même si j'apprécie les réponses concernant jQuery vs plaine javascript performance, je cherche en fait beaucoup plus de réponses quantitatives. lors de l'utilisation de jQuery , les cas où il serait préférable (lisibilité/compacité) d'utiliser le javascript au lieu d'utiliser $() . En plus de l'exemple que j'ai donné dans ma question initiale.

228
demandé sur j08691 2011-01-11 00:53:40

13 réponses

  • this.id (comme vous le savez)
  • this.value (sur la plupart des types d'entrée. seuls les problèmes que je connais sont IE quand un <select> n'a pas value propriétés définies sur ses <option> éléments, ou des entrées radio en Safari.)
  • this.className pour obtenir ou placer un bien entier de la "catégorie
  • this.selectedIndex contre <select> pour obtenir l'index sélectionné
  • this.options contre une <select> pour obtenir une liste des "éléments" 151980920 1519530920"
  • this.text contre un <option> pour obtenir son contenu textuel
  • this.rows contre un <table> pour obtenir une collection de <tr> elements
  • this.cells contre un <tr> pour obtenir ses cellules (td & th)
  • this.parentNode pour obtenir un parent direct
  • this.checked pour obtenir l'état coché d'un checkbox Merci @Tim Bas
  • this.selected pour obtenir l'état d'un option Merci @Tim Bas
  • this.disabled pour obtenir l'état de handicap d'un input Merci @Tim Down
  • this.readOnly pour obtenir l'état en lecture seule d'un input Merci @Tim Down
  • this.href contre un <a> élément pour obtenir son href
  • this.hostname contre un <a> élément pour obtenir le domaine de son href
  • this.pathname contre un <a> élément pour obtenir le chemin de son href
  • this.search contre un élément <a> pour obtenir le querystring de son href
  • this.src contre un élément où il est valide pour avoir un src

...Je pense que vous obtenez l'idée.

il y aura des moments où la performance est cruciale. Comme si vous exécutez quelque chose dans une boucle plusieurs fois, vous pourriez vouloir abandonner jQuery.

en général, vous pouvez remplacer:

$(el).attr('someName');

avec:

ci-dessus était mal formulé. getAttribute n'est pas un remplacement, mais il récupère la valeur d'un attribut envoyé depuis le serveur, et son setAttribute correspondant le définira. Nécessaire dans certains cas.

les phrases ci-dessous la recouvraient en quelque sorte. Voir cette réponse pour un meilleur traitement.

el.getAttribute('someName');

... afin d'accéder directement à un attribut. Notez que les attributs ne sont pas les mêmes que les propriétés (bien qu'ils se reflètent parfois). Bien sûr, il y a setAttribute aussi.

dites que vous aviez une situation où vous avez reçu une page où vous devez déballer toutes les étiquettes d'un certain type. Il est court et facile avec jQuery:

$('span').unwrap();  // unwrap all span elements

mais s'il y en a beaucoup, vous pouvez faire un peu D'API DOM native:

var spans = document.getElementsByTagName('span');

while( spans[0] ) {
    var parent = spans[0].parentNode;
    while( spans[0].firstChild ) {
        parent.insertBefore( spans[0].firstChild, spans[0]);
    }
    parent.removeChild( spans[0] );
}

ce code est assez court, il fonctionne mieux que la version jQuery, et peut facilement être transformé en une fonction réutilisable dans votre bibliothèque personnelle.

il peut sembler que j'ai une boucle infinie avec le while externe à cause de while(spans[0]) , mais parce que nous avons affaire à une" liste en direct "il est mis à jour quand nous faisons le parent.removeChild(span[0]); . Il s'agit d'une fonctionnalité assez astucieuse que nous manquons lorsque nous travaillons avec un tableau (ou un objet similaire à un tableau) à la place.

202
répondu user113716 2017-05-23 12:09:57

la bonne réponse est que vous allez toujours prendre une pénalité de performance en utilisant jQuery au lieu de 'vieux' JavaScript natif. C'est parce que jQuery est une bibliothèque JavaScript. Ce N'est pas une nouvelle version de JavaScript.

la raison pour laquelle jQuery est puissant est qu'il fait certaines choses qui sont trop fastidieux dans une situation de cross-browser (AJAX est l'un des meilleurs exemples) et lisses sur les incohérences entre les multitude de navigateurs disponibles et fournit une API cohérente. Il facilite aussi facilement des concepts tels que l'enchaînement, l'itération implicite, etc., pour simplifier le travail sur des groupes d'éléments ensemble.

apprendre le jquery n'est pas un substitut pour apprendre le JavaScript. Vous devriez avoir une base solide dans le dernier afin que vous compreniez pleinement ce que la connaissance du premier rend plus facile pour vous.

-- révisé pour inclure les commentaires --

comme le les commentaires ne tardent pas à souligner (et je suis d'accord à 100%) que les énoncés ci-dessus font référence au Code d'analyse comparative. Une solution JavaScript "native" (en supposant qu'elle soit bien écrite) surpassera une solution jQuery qui accomplit la même chose dans presque tous les cas (j'aimerais voir un exemple autrement). jQuery accélère le temps de développement, ce qui est un avantage significatif que je ne veux pas minimiser. Il facilite facile à lire, facile à suivre, code, ce qui est plus que certains développeurs sont capables de créer sur leur propre.

À mon avis, alors, la réponse dépend de ce que vous tentez d'atteindre. Si, comme je l'ai supposé d'après votre référence aux avantages de performance, vous êtes après la meilleure vitesse possible hors de votre application, alors en utilisant jQuery introduit overhead chaque fois que vous appelez $() . Si vous optez pour la lisibilité, la cohérence, la compatibilité entre navigateurs, etc., il y a certainement des raisons de préférer jQuery au JavaScript "natif".

59
répondu g.d.d.c 2011-01-10 22:36:36

il y a un cadre appelé... oh devinez quoi? Vanilla JS . J'espère que vous obtenez la plaisanterie... : D il sacrifie la lisibilité du code pour la performance... En le comparant à jQuery ci-dessous, vous pouvez voir que récupérer un élément DOM par ID est presque 35X plus rapide. :)

donc si vous voulez de la performance, vous feriez mieux d'essayer Vanilla JS et de tirer vos propres conclusions. Peut-être que vous ne verrez pas JavaScript suspendre le GUI du navigateur / verrouillage du thread pendant le code intensif comme dans une boucle for .

Vanilla JS est un cadre rapide, léger, construire des applications JavaScript incroyables et puissantes.

sur leur page d'accueil il y a quelques comparaisons de perf:

enter image description here

36
répondu Leniel Macaferi 2013-04-30 16:51:57

il y a déjà une réponse acceptée, mais je crois qu'aucune réponse tapée directement ici ne peut être complète dans sa liste de méthodes/attributs javascript natif qui a pratiquement garanti le soutien cross-browser. Pour cela je peux vous rediriger vers quirksmode:

http://www.quirksmode.org/compatibility.html

c'est peut-être la liste la plus complète de ce qui fonctionne et de ce qui ne fonctionne pas sur quel navigateur n'importe où. Payer attention particulière à la section DOM. Il y a beaucoup à lire, mais le point n'est pas de tout lire mais de l'utiliser comme une référence.

lorsque j'ai commencé à écrire sérieusement des applications web, j'ai imprimé Toutes les tables DOM et les ai accrochées au mur pour que je sache d'un seul coup d'œil ce qui est sûr à utiliser et ce qui nécessite des piratages. Ces jours-ci je viens de google quelque chose comme quirksmode parentNode compatibility quand j'ai des doutes.

comme toute autre chose, le jugement est surtout une question d'expérience. Je ne serait pas vraiment vous recommander de lire l'ensemble du site et de mémoriser toutes les questions pour savoir quand utiliser jQuery et quand utiliser du JS. Juste être conscient de la liste. Il est assez facile de recherche. Avec le temps, vous développerez un instinct de quand js simple est préférable.


PS: PPK (l'auteur du site) a aussi un très beau livre que je recommande la lecture

17
répondu slebetman 2011-01-11 04:14:50

quand:

  1. vous savez qu'il est inébranlable de la croix-prise en charge du navigateur pour ce que vous faites, et
  2. il n'est pas beaucoup plus de code à type, et
  3. il n'est pas significativement moins lisible, et
  4. vous êtes raisonnablement sûr que jQuery ne choisira pas différentes implémentations basées sur le navigateur pour obtenir de meilleures performances, puis:

utilisation JavaScript. Sinon, utilisez jQuery (si vous le pouvez).

Edit : cette réponse s'applique à la fois lors du choix d'utiliser jQuery dans son ensemble par opposition à le laisser en dehors, ainsi que le choix d'utiliser ou non vanilla JS à l'intérieur de jQuery. Choisir entre attr('id') et .id penche en faveur de JS, tandis que choisir entre removeClass('foo') versus .className = .className.replace( new Regexp("(?:^|\s+)"+foo+"(?:\s+|$)",'g'), '' ) penche en faveur de jQuery.

14
répondu Phrogz 2011-01-10 22:24:18

D'autres réponses se sont concentrées sur la question générale de "jQuery vs. plain JS."À en juger par votre opération, je pense que vous vous demandiez simplement quand il est préférable d'utiliser vanilla JS si vous avez déjà choisi d'utiliser jQuery. Votre exemple est un exemple parfait du moment où vous devriez utiliser vanilla JS:

$(this).attr('id');

est à la fois plus lent et (à mon avis) moins lisible que:

this.id .

c'est plus lent parce que vous devez lancer un nouvel objet JS juste pour récupérer l'attribut de la manière jQuery. Maintenant, si vous allez utiliser $(this) pour effectuer d'autres opérations, alors par tous les moyens, stocker cet objet jQuery dans une variable et opérer avec cela. Cependant, j'ai rencontré de nombreuses situations où j'ai juste besoin d'un attribut de l'élément (comme id ou src ).

Existe-t-il d'autres pratiques communes de cette façon? Où certains JavaScript les opérations pourraient être accomplies plus facile, sans faire entrer jQuery dans mélange. Ou est-ce un cas rare? (d'un jQuery "raccourci" nécessitant effectivement plus de code)

je pense que le cas le plus commun est celui que vous décrivez dans votre post; les gens enveloppant $(this) dans un objet jQuery inutilement. Je le vois le plus souvent avec id et value (au lieu d'utiliser $(this).val() ).

Modifier: ici est un article qui explique pourquoi en utilisant jQuery dans le cas attr() est plus lent. Confession: je l'ai volé de la balise wiki, mais je pense que cela vaut la peine de le mentionner pour la question.

éditer à nouveau: étant donné les implications de la lisibilité/performance de simplement accéder aux attributs directement, je dirais qu'une bonne règle de base est probablement d'essayer d'utiliser this.<attributename> lorsque possible. Y sont probablement quelques cas où cela ne fonctionnera pas en raison d'incohérences de navigateur, mais il est probablement préférable d'essayer cette première et de retomber sur jQuery si elle ne fonctionne pas.

13
répondu Andrew Whitaker 2011-01-10 23:01:56

si vous êtes surtout préoccupé par la performance, votre exemple principal frappe le clou sur la tête. Invoquer jQuery inutilement ou de façon redondante est, IMHO, la deuxième cause principale de la lenteur des performances (la première étant la mauvaise DOM traversal).

ce n'est pas vraiment un exemple de ce que vous cherchez, mais je le vois si souvent qu'il vaut la peine de le mentionner: une des meilleures façons d'accélérer la performance de vos scripts jQuery est de mettre en cache des objets jQuery, et / ou utiliser le chaînage:

// poor
$(this).animate({'opacity':'0'}, function() { $(this).remove(); });

// excellent
var element = $(this);
element.animate({'opacity':'0'}, function() { element.remove(); });

// poor
$('.something').load('url');
$('.something').show();

// excellent
var something = $('#container').children('p.something');
something.load('url').show();
9
répondu Stephen 2011-01-10 22:09:18

j'ai trouvé qu'il y a certainement chevauchement entre JS et JQ. Le code que vous avez indiqué est un bon exemple. Franchement, la meilleure raison d'utiliser JQ sur JS est tout simplement la compatibilité du navigateur. Je me penche toujours vers JQ, même si je peux accomplir quelque chose en JS.

7
répondu Dutchie432 2011-01-10 21:57:51

C'est mon point de vue personnel, mais comme jQuery est JavaScript de toute façon, je pense qu'en théorie, il ne peut pas fonctionner mieux que vanilla JS jamais.

mais en pratique, il peut donner de meilleurs résultats que JS écrit à la main, car le code écrit à la main peut ne pas être aussi efficace que jQuery.

résultat-pour les petites choses, j'ai tendance à utiliser vanilla JS, pour les projets intensifs JS j'aime utiliser jQuery et ne pas réinventer la roue - c'est aussi plus productif.

6
répondu CodeVirtuoso 2018-03-18 00:51:53

la première liste de propriétés en direct de la réponse this comme élément DOM est tout à fait complète.

vous pouvez trouver aussi intéressant de connaître d'autres.

quand il s'agit du document:

  • this.forms pour obtenir un HTMLCollection des formulaires actuels,
  • this.anchors pour obtenir un HTMLCollection de tous les HTMLAnchorElements avec name étant mis,
  • this.links pour obtenir un HTMLCollection de tous les HTMLAnchorElement s avec href étant défini,
  • this.images pour obtenir un HTMLCollection de tous les HTMLImageElement s
  • et le même avec les applets dépréciés que this.applets

quand vous travaillez avec document.forms , document.forms[formNameOrId] obtient la forme ainsi nommée ou identifiée.

Lorsqu'il s'agit d'un formulaire:

  • this[inputNameOrId] pour obtenir le champ ainsi nommé ou identifié

quand il s'agit du champ de formulaire:

  • this.type pour obtenir le type de champ

lorsque nous apprenons les sélecteurs jQuery, nous sautons souvent l'apprentissage des propriétés HTML elements déjà existantes, qui sont si rapides à accéder.

3
répondu lib3d 2013-03-23 16:28:51

$(this) est différent de this :

en utilisant $(this) vous vous assurez que le prototype jQuery est transmis à l'objet.

1
répondu John Green 2011-09-21 12:58:45

comme d'habitude, je suis en retard à cette fête.

Ce n'était pas la fonctionnalité supplémentaire qui m'a fait décider d'utiliser jQuery, aussi attrayant que c'était. Après tout rien ne vous empêche de créer vos propres fonctions.

c'était le fait qu'il y avait tellement de trucs à apprendre lors de la modification du DOM pour éviter les fuites de mémoire (je parle de vous IE). Avoir une ressource centrale qui a géré toutes ces sortes de questions pour moi, écrits par des gens qui ont un des codeurs JS bien meilleurs que je ne le serai jamais, qui étaient continuellement révisés, révisés et testés était Dieu envoyé.

je suppose que ce genre de chose tombe sous l'argument de soutien/abstraction de navigateur croisé.

et bien sûr jQuery n'empêche pas l'utilisation de JS droit quand vous en aviez besoin. J'ai toujours senti l'air de fonctionner ensemble.

bien sûr si votre navigateur n'est pas supporté par jQuery ou si vous supportez un environnement bas de gamme (téléphone plus ancien?) alors un grand .js fichier peut être un problème. Tu te souviens quand jQuery était petit?

Mais normalement, la différence de performances n'est pas un sujet de préoccupation. Il suffit que ce soit assez rapide. Avec les gigahertz de cycles CPU qui vont se gaspiller à chaque seconde, je suis plus préoccupé par la performance de mes codeurs, les seules ressources de développement qui ne doublent pas en puissance tous les 18 mois.

qui dit que je suis en train d'examiner problèmes d'accessibilité et apparemment .innerHTML est un peu un non non avec ça. jQuery bien sûr dépend de .innerHTML, donc maintenant je suis à la recherche d'un cadre qui dépendra des méthodes quelque peu fastidieux qui sont autorisés. Et je peux imaginer qu'un tel cadre fonctionnera plus lentement que jQuery, mais tant qu'il fonctionne assez bien, je serai heureux.

1
répondu Swanny 2013-12-06 05:17:52

Voici une réponse non technique-de nombreux emplois peuvent ne pas permettre certaines bibliothèques, comme jQuery.

en fait, en fait, Google n'autorise jQuery dans aucun de leurs codes (ni React, parce qu'il appartient à Facebook), ce que vous pourriez ne pas avoir connu jusqu'à ce que l'intervieweur dit"Désolé, mais vous ne pouvez pas utiliser jQuery, il n'est pas sur la liste approuvée à la société XYZ". JavaScript vanille fonctionne absolument partout, à chaque fois, et ne vous donnera jamais ce problème. Si vous comptez sur une bibliothèque oui vous obtenez la vitesse et la facilité, mais vous perdez l'universalité.

aussi, en parlant d'entrevue, l'autre inconvénient est que si vous dites que vous avez besoin d'utiliser une bibliothèque pour résoudre un problème JavaScript lors d'un quiz code, il apparaît comme vous ne comprenez pas réellement le problème, qui semble un peu mauvais. Alors que si vous le résolvez en JavaScript brut vanille il démontre que vous comprenez réellement et pouvez résoudre chaque partie de n'importe quel problème qu'ils jettent en face de vous.

1
répondu Jack Connor 2018-03-18 00:46:43