J'ai entendu à plusieurs reprises que l'atout le plus important de jQuery est la manière dont il interroge et manipule les éléments du DOM: vous pouvez utiliser des requêtes CSS pour créer des requêtes complexes qui seraient très difficiles à exécuter avec du javascript normal. Toutefois, autant que je sache, vous pouvez obtenir le même résultat avec document.querySelector
ou document.querySelectorAll
, qui sont pris en charge dans Internet Explorer 8 et versions ultérieures.
La question est donc la suivante: pourquoi "risquer"-t-il les frais généraux de jQuery si son actif le plus puissant peut être réalisé avec du JavaScript pur?
Je sais que jQuery a plus que des sélecteurs CSS, par exemple le navigateur AJAX, l'attachement d'événements Nice, etc. Mais sa partie interrogation est une très grande partie de la force de jQuery!
Des pensées?
document.querySelectorAll()
présente plusieurs incohérences entre les navigateurs et n'est pas pris en charge par les anciens navigateursCela ne causera probablement plus de problèmes de nos jours. Il a un très peu intuitif mécanisme de cadrage et quelques autres fonctionnalités pas si belles . De plus, avec javascript, vous aurez plus de difficulté à travailler avec les ensembles de résultats de ces requêtes, ce que vous voudrez peut-être souvent faire. jQuery fournit des fonctions pour les utiliser, telles que: filter()
, find()
, children()
, parent()
, map()
, not()
et plusieurs autres. Sans parler de la capacité de jQuery à travailler avec des sélecteurs de pseudo-classes.
Cependant, je ne considérerais pas ces choses comme les fonctionnalités les plus puissantes de jQuery, mais plutôt comme "travailler" sur le dom (événements, styling, animation et manipulation) dans un compatible avec crossbrowser manière ou l'interface ajax.
Si vous ne voulez que le moteur de sélection de jQuery, vous pouvez utiliser celui que jQuery utilise lui-même: Sizzle Ainsi, vous avez puissance du moteur jQuerys Selector sans les frais généraux.
EDIT: Juste pour mémoire, je suis un grand fan de JavaScript Vanilla. Néanmoins, il est parfois nécessaire d'avoir 10 lignes de code JavaScript pour écrire une ligne jQuery.
Bien sûr, vous devez être discipliné pour ne pas écrire jQuery comme ceci:
$('ul.first').find('.foo').css('background-color', 'red').end().find('.bar').css('background-color', 'green').end();
C'est extrêmement difficile à lire, alors que le dernier est assez clair:
$('ul.first')
.find('.foo')
.css('background-color', 'red')
.end()
.find('.bar')
.css('background-color', 'green')
.end();
Le code JavaScript équivalent serait bien plus complexe illustré par le pseudocode ci-dessus:
1) Trouvez l’élément, envisagez de prendre tous les éléments ou seulement le premier.
// $('ul.first')
// taking querySelectorAll has to be considered
var e = document.querySelector("ul.first");
2) Parcourez le tableau de nœuds enfants via des boucles (éventuellement imbriquées ou récursives) et vérifiez la classe (la liste de classes n'est pas disponible dans tous les navigateurs!)
//.find('.foo')
for (var i = 0;i<e.length;i++){
// older browser don't have element.classList -> even more complex
e[i].children.classList.contains('foo');
// do some more magic stuff here
}
3) appliquer le style css
// .css('background-color', 'green')
// note different notation
element.style.backgroundColor = "green" // or
element.style["background-color"] = "green"
Ce code serait au moins deux fois plus de lignes de code que vous écrivez avec jQuery. En outre, vous devrez également envisager des problèmes inter-navigateurs susceptibles de compromettre le avantage en termes de rapidité (outre la fiabilité) du code natif.
Si vous optimisez votre page pour IE8 ou une version plus récente, vous devez vraiment déterminer si vous avez besoin de jquery ou non. Les navigateurs modernes disposent de nombreux actifs que jquery fournit en mode natif.
Si vous vous souciez de la performance, vous pouvez bénéficier d’incroyables avantages en termes de performances (2 à 10 fois plus rapide) en utilisant natif. javascript: http://jsperf.com/jquery-vs-native-selector-and-element-style/2
J'ai transformé un div-tagcloud de jquery en javascript natif (compatible IE8 +), les résultats sont impressionnants. 4 fois plus vite avec juste un peu de frais généraux.
Number of lines Execution Time
Jquery version : 340 155ms
Native version : 370 27ms
Vous n’auriez peut-être pas besoin de Jquery fournit une vue d’ensemble vraiment agréable, que les méthodes natives remplacent pour quelle version de navigateur.
http://youmightnotneedjquery.com/
Annexe: Comparaisons de vitesse supplémentaires entre la concurrence entre les méthodes natives et jquery
Pour comprendre pourquoi jQuery est si populaire, il est important de comprendre d'où nous venons!
Il y a environ une décennie, les principaux navigateurs étaient IE6, Netscape 8 et Firefox 1.5. À l'époque, il n'existait que peu de méthodes inter-navigateurs permettant de sélectionner un élément dans le DOM Document.getElementById()
.
Donc, quand jQuery a été publié en 2006 , c'était plutôt révolutionnaire. À l'époque, jQuery a défini le standard en matière de sélection/modification simple des éléments HTML et des événements déclencheurs, car sa flexibilité et la prise en charge du navigateur étaient sans précédent.
Plus de dix ans plus tard, de nombreuses fonctionnalités qui ont rendu jQuery si populaire ont été intégrées au standard javaScript:
$()
, vous pouvez maintenant utiliser Document.querySelectorAll()
$el.on()
, vous pouvez maintenant utiliser EventTarget.addEventListener()
$el.toggleClass()
, vous pouvez maintenant utiliser Element.classList.toggle()
Celles-ci n'étaient généralement pas disponibles en 2005. Le fait qu'elles le soient aujourd'hui pose évidemment la question de savoir pourquoi nous devrions utiliser jQuery. Et en effet, les gens se demandent de plus en plus si nous devrions utiliser jQuery .
Donc, si vous pensez comprendre assez le JavaScript pour vous passer de jQuery, faites-le! Ne vous sentez pas obligé d'utiliser jQuery, simplement parce que tant d'autres le font!
le moteur de sélection Sizzle de jQuery peut utiliser querySelectorAll
s'il est disponible. Elle élimine également les incohérences entre les navigateurs pour obtenir des résultats uniformes. Si vous ne voulez pas utiliser tout jQuery, vous pouvez simplement utiliser Sizzle séparément. C'est une roue assez fondamentale à inventer.
Voici quelques extraits de la source qui montrent le genre de choses que jQuery (w/Sizzle) règle pour vous:
Mode Safari quirks:
if ( document.querySelectorAll ) {
(function(){
var oldSizzle = Sizzle,
div = document.createElement("div"),
id = "__sizzle__";
div.innerHTML = "<p class='TEST'></p>";
// Safari can't handle uppercase or unicode characters when
// in quirks mode.
if ( div.querySelectorAll && div.querySelectorAll(".TEST").length === 0 ) {
return;
}
Si cette protection échoue, elle utilise une version de Sizzle qui n'est pas améliorée avec querySelectorAll
. Plus bas, vous trouverez des descripteurs spécifiques pour les incohérences dans les navigateurs IE, Opera et Blackberry.
// Check parentNode to catch when Blackberry 4.6 returns
// nodes that are no longer in the document #6963
if ( elem && elem.parentNode ) {
// Handle the case where IE and Opera return items
// by name instead of ID
if ( elem.id === match[3] ) {
return makeArray( [ elem ], extra );
}
} else {
return makeArray( [], extra );
}
Et si tout échoue, le résultat de oldSizzle(query, context, extra, seed)
sera renvoyé.
C'est parce que jQuery peut faire beaucoup plus que querySelectorAll
.
Tout d'abord, jQuery (et Sizzle, en particulier) fonctionne pour les navigateurs plus anciens, comme IE7-8, qui ne prennent pas en charge les sélecteurs CSS2.1-3.
De plus, Sizzle (qui est le moteur de sélection derrière jQuery) vous propose un grand nombre d’instruments de sélection plus avancés, comme la pseudo-classe :selected
, un sélecteur avancé :not()
, une syntaxe plus complexe comme dans $("> .children")
et ainsi de suite.
Et il le fait à travers les navigateurs, sans faille, offrant tout ce que jQuery peut offrir (plugins et API).
Oui, si vous pensez pouvoir compter sur de simples sélecteurs de classe et d’identifiant, jQuery est trop pour vous et vous rapporteriez un résultat exagéré. Mais si vous ne le faites pas et que vous souhaitez tirer parti de toutes les qualités de jQuery, utilisez-le.
Voici une comparaison si je veux appliquer le même attribut, par exemple. cache tous les éléments de la classe "my-class". C'est une des raisons d'utiliser jQuery.
jQuery:
$('.my-class').hide();
JavaScript:
var cls = document.querySelectorAll('.my-class');
for (var i = 0; i < cls.length; i++) {
cls[i].style.display = 'none';
}
Avec jQuery déjà si populaire, ils auraient dû faire en sorte que document.querySelector () se comporte exactement comme $ (). À la place, document.querySelector () ne sélectionne que le premier élément correspondant, ce qui le rend utile à moitié.
En termes de maintenabilité du code, il y a plusieurs raisons de s'en tenir à une bibliothèque largement utilisée.
L'un des principaux est qu'ils sont bien documentés et qu'ils ont des communautés telles que ... disons ... stackexchange, où l'on peut trouver de l'aide avec les bibliothèques. Avec une bibliothèque codée sur mesure, vous disposez du code source et peut-être d'un document explicatif, à moins que le ou les codeurs aient passé plus de temps à documenter le code qu'à l'écrire, ce qui est extrêmement rare.
Écrire votre propre bibliothèque peut fonctionner pour vous, mais le stagiaire assis au bureau suivant aura peut-être plus de facilité à se familiariser avec quelque chose comme jQuery.
Appelez-le effet de réseau si vous le souhaitez. Cela ne veut pas dire que le code sera supérieur dans jQuery; la nature concise du code facilite la compréhension de la structure globale des programmeurs de tous les niveaux de compétence, ne serait-ce que parce qu'il existe davantage de code fonctionnel visible en une fois dans le fichier que vous visualisez. En ce sens, 5 lignes de code valent mieux que 10.
Pour résumer, jQuery présente les principaux avantages suivants: code concis et ubiquité.
Je pense que la vraie réponse est que jQuery a été développé bien avant que querySelector/querySelectorAll
ne soit disponible sur tous les principaux navigateurs.
La version initiale de jQuery était en 2006 . En fait, même jQuery n'était pas le premier à implémenter les sélecteurs CSS .
IE était le dernier navigateur pour implémenter querySelector/querySelectorAll
. Sa 8ème version sortie en 2009 .
Alors maintenant, les sélecteurs d’éléments DOM ne sont plus le point fort de jQuery. Cependant, il a encore beaucoup de choses intéressantes dans sa manche, comme des raccourcis pour changer le contenu CSS et HTML de l'élément, des animations, des événements liés, ajax.
comme le dit le site officiel: "jQuery: la bibliothèque d'écriture moins, plus, JavaScript"
essayez de traduire le code jQuery suivant sans aucune bibliothèque
$("p.neat").addClass("ohmy").show("slow");
Vieille question, mais une demi-décennie plus tard, cela vaut la peine de revenir. Ici, je ne discute que de l’aspect sélecteur de jQuery.
document.querySelector[All]
est pris en charge par tous les navigateurs actuels, jusqu'à IE8, de sorte que la compatibilité n'est plus un problème. J’ai également constaté qu’il n’y avait aucun problème de performances (il était supposé être plus lent que document.getElementById
, mais mes propres tests suggèrent qu’il est légèrement plus rapide).
Par conséquent, lorsqu'il s'agit de manipuler directement un élément, il est préférable de le préférer à jQuery.
Par exemple:
var element=document.querySelector('h1');
element.innerHTML='Hello';
est largement supérieur à:
var $element=$('h1');
$element.html('hello');
Pour pouvoir faire quoi que ce soit, jQuery doit parcourir une centaine de lignes de code (j'ai déjà parcouru un code tel que celui ci-dessus pour voir ce que jQuery en faisait réellement). C’est clairement une perte de temps pour tout le monde.
L'autre coût important de jQuery est le fait qu'il englobe tout dans un nouvel objet jQuery. Cette surcharge est particulièrement inutile si vous devez déplier à nouveau l'objet ou utiliser l'une des méthodes d'objet pour gérer les propriétés déjà exposées sur l'élément d'origine.
Cependant, jQuery a un avantage dans la façon dont il gère les collections. Si l'exigence est de définir les propriétés de plusieurs éléments, jQuery a une méthode intégrée each
qui permet quelque chose comme ceci:
var $elements=$('h2'); // multiple elements
$elements.html('hello');
Pour le faire avec Vanilla JavaScript nécessiterait quelque chose comme ceci:
var elements=document.querySelectorAll('h2');
elements.forEach(function(e) {
e.innerHTML='Hello';
});
que certains trouvent intimidant.
les sélecteurs jQuery sont également légèrement différents, mais les navigateurs modernes (à l’exclusion de IE8) n’en tireront pas grand avantage.
En règle générale, je mets en garde contre l'utilisation de jQuery pour les nouveaux projets:
Si rien de ce qui précède n'a d'importance, faites ce que vous voulez. Cependant, jQuery n'est plus aussi important que par le passé pour le développement multiplate-forme, car les codes JavaScript et CSS modernes vont beaucoup plus loin qu'auparavant.
Cela ne fait aucune mention des autres fonctionnalités de jQuery. Cependant, je pense qu’eux aussi ont besoin d’être examinés de plus près.
$ ("# id") vs document.querySelectorAll ("# id")
L’accord porte sur la fonction $ (). Il crée un tableau puis le divise pour vous, mais avec document.querySelectorAll (), il crée un tableau et vous devez le rompre.
Juste un commentaire à ce sujet, lorsqu’on utilise Material Design Lite, le sélecteur JQuery ne renvoie pas la propriété correspondante pour une raison quelconque.
Pour:
<div class="logonfield mdl-textfield mdl-js-textfield mdl-textfield--floating-label">
<input class="mdl-textfield__input" type="text" id="myinputfield" required>
<label class="mdl-textfield__label" for="myinputfield">Enter something..</label>
</div>
Cela marche:
document.querySelector('#myinputfield').parentNode.MaterialTextfield.change();
Cela ne veut pas:
$('#myinputfield').parentNode.MaterialTextfield.change();