jQuery vs document.querySelectorAll

Escuché varias veces que el activo más fuerte de jQuery es la forma en que consulta y manipula elementos en el DOM: puede usar consultas CSS para crear consultas complejas que serían muy difíciles de hacer en JavaScript normal. Sin embargo, hasta donde yo sé, puede lograr el mismo resultado con document.querySelectoro document.querySelectorAll, que son compatibles con Internet Explorer 8 y versiones posteriores.

Entonces la pregunta es esta: ¿por qué 'arriesgar' los gastos generales de jQuery si su activo más fuerte se puede lograr con JavaScript puro?

Sé que jQuery tiene más que solo selectores de CSS, por ejemplo, navegador cruzado AJAX, buena vinculación de eventos, etc. ¡Pero su parte de consulta es una parte muy importante de la fortaleza de jQuery!

¿Alguna idea?

document.querySelectorAll() tiene varias inconsistencias en los navegadores y no es compatible con los navegadores más antiguos. ^{Esto probablemente ya no cause ningún problema hoy en día} . Tiene un mecanismo de alcance muy poco intuitivo y algunas otras características no tan agradables . Además, con javascript le resulta más difícil trabajar con los conjuntos de resultados de estas consultas, que en muchos casos es posible que desee hacer. jQuery proporciona funciones para trabajar en ellos como: filter(), find(), children(), parent(), map(), not()y varios más. Sin mencionar la capacidad de jQuery para trabajar con selectores de pseudo-clase.

Sin embargo, no consideraría estas cosas como las características más fuertes de jQuery, sino otras cosas como "trabajar" en el dom (eventos, estilo, animación y manipulación) de una manera compatible con crossbrowser o la interfaz ajax.

Si solo desea el motor selector de jQuery, puede usar el que está usando jQuery: Sizzle De esa manera tiene el poder del motor jQuerys Selector sin la desagradable sobrecarga.

EDITAR: Solo para el registro, soy un gran fan de JavaScript de vainilla. Sin embargo, es un hecho que a veces necesitas 10 líneas de JavaScript donde escribirías 1 línea jQuery.

Por supuesto, debes ser disciplinado para no escribir jQuery así:

$('ul.first').find('.foo').css('background-color', 'red').end().find('.bar').css('background-color', 'green').end();

Esto es extremadamente difícil de leer, mientras que este último es bastante claro:

$('ul.first')
   .find('.foo')
      .css('background-color', 'red')
.end()
   .find('.bar')
      .css('background-color', 'green')
.end();

El JavaScript equivalente sería mucho más complejo ilustrado por el pseudocódigo anterior:

1) Encuentra el elemento, considera tomar todo el elemento o solo el primero.

// $('ul.first')
// taking querySelectorAll has to be considered
var e = document.querySelector("ul.first");

2) Itere sobre la matriz de nodos secundarios a través de algunos bucles (posiblemente anidados o recursivos) y verifique la clase (¡la lista de clases no está disponible en todos los navegadores!)

//.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) aplica el estilo CSS

// .css('background-color', 'green')
// note different notation
element.style.backgroundColor = "green" // or
element.style["background-color"] = "green"

Este código tendría al menos el doble de líneas de código que escribe con jQuery. También debería tener en cuenta los problemas entre navegadores que comprometerán la gran ventaja de velocidad (además de la confiabilidad) del código nativo.

Si está optimizando su página para IE8 o más reciente, realmente debería considerar si necesita jquery o no. Los navegadores modernos tienen muchos recursos nativos que proporciona jquery.

Si le importa el rendimiento, puede obtener increíbles beneficios de rendimiento (2-10 más rápido) utilizando JavaScript nativo: http://jsperf.com/jquery-vs-native-selector-and-element-style/2

Transformé un div-tagcloud de jquery a javascript nativo (compatible con IE8 +), los resultados son impresionantes. 4 veces más rápido con solo un poco de sobrecarga.

                    Number of lines       Execution Time                       
Jquery version :        340                    155ms
Native version :        370                    27ms

Es posible que no necesite Jquery proporciona una visión general realmente agradable, que los métodos nativos reemplazan por la versión del navegador.

http://youmightnotneedjquery.com/

Apéndice: más comparaciones de velocidad de cómo los métodos nativos compiten con jquery

• Array: $ .inArray vs Array.indexOf: Jquery 24% más lento

• DOM: $ .empty vs Node.innerHtml: Jquery 97% más lento

• DOM: $ .on vs Node.addEventListener: Jquery 90% más lento

• DOM: $ .find vs Node.queryselectorall: Jquery 90% más lento

• Array: $ .grep vs Array.filter: nativo 70% más lento

• DOM: $ .show / hide vs display none: Jquery 85% más lento

• AJAX: $ .ajax vs XMLHttpRequest: Jquery 89% más lento

• Altura: $ .outerHeight vs offsetHeight: Jquery 87% más lento

• Attr: $ .attr vs setAttribute: Jquery 86% más lento

Para entender por qué jQuery es tan popular, ¡es importante entender de dónde venimos!

Hace aproximadamente una década, los principales navegadores eran IE6, Netscape 8 y Firefox 1.5. En aquellos días, había pequeñas formas de navegador cruzado para seleccionar un elemento del DOM además Document.getElementById().

Entonces, cuando jQuery fue lanzado en 2006 , fue bastante revolucionario. En aquel entonces, jQuery estableció el estándar sobre cómo seleccionar / cambiar fácilmente elementos HTML y desencadenar eventos, porque su flexibilidad y compatibilidad con el navegador no tenían precedentes.

Ahora, más de una década después, muchas características que hicieron que jQuery fuera tan popular se han incluido en el estándar javaScript:

• En lugar de jQuery $(), ahora puede usarDocument.querySelectorAll()
• En lugar de jQuery $el.on(), ahora puede usarEventTarget.addEventListener()
• En lugar de jQuery $el.toggleClass(), ahora puede usarElement.classList.toggle()
• ...

En general, estos no estaban disponibles en 2005. El hecho de que lo estén hoy obviamente plantea la pregunta de por qué deberíamos usar jQuery. Y, de hecho, la gente se pregunta cada vez más si deberíamos usar jQuery .

Entonces, si crees que entiendes JavaScript lo suficientemente bien como para prescindir de jQuery, ¡hazlo! ¡No te sientas obligado a usar jQuery, solo porque muchos otros lo están haciendo!

Eso es porque jQuery puede hacer mucho más que querySelectorAll.

En primer lugar, jQuery (y Sizzle, en particular), funciona para navegadores más antiguos como IE7-8 que no admiten selectores CSS2.1-3.

Además, Sizzle (que es el motor de selección detrás de jQuery) le ofrece muchos instrumentos de selección más avanzados, como la :selectedpseudoclase, un :not()selector avanzado , una sintaxis más compleja, $("> .children")etc.

Y lo hace en todos los navegadores, sin problemas, ofreciendo todo lo que jQuery puede ofrecer (complementos y API).

Sí, si cree que puede confiar en simples selectores de clase e identificación, jQuery es demasiado para usted y estaría pagando una recompensa exagerada. Pero si no lo hace y desea aprovechar todas las bondades de jQuery, úsela.

El motor selector de jQuery Sizzle se puede usar querySelectorAllsi está disponible. También suaviza las inconsistencias entre los navegadores para lograr resultados uniformes. Si no desea usar todo jQuery, puede usar Sizzle por separado. Esta es una rueda fundamental para inventar.

Aquí hay algunas selecciones de cerezas de la fuente que muestran el tipo de cosas que jQuery (con Sizzle) resuelve para usted:

Modo de peculiaridades de Safari:

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 ese guardia falla, usa una versión de Sizzle que no está mejorada querySelectorAll. Más abajo hay identificadores específicos para inconsistencias en IE, Opera y el navegador 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 );
  }

Y si todo lo demás falla, devolverá el resultado de oldSizzle(query, context, extra, seed).

En términos de mantenimiento del código, hay varias razones para seguir con una biblioteca ampliamente utilizada.

Uno de los principales es que están bien documentados y tienen comunidades como ... digamos ... stackexchange, donde se puede encontrar ayuda con las bibliotecas. Con una biblioteca codificada personalizada, tiene el código fuente, y tal vez un documento de instrucciones, a menos que el (los) codificador (es) pasen más tiempo documentando el código que escribiéndolo, lo cual es muy raro.

Escribir su propia biblioteca podría funcionar para usted , pero al pasante que se sienta en el escritorio de al lado puede ser más fácil ponerse al día con algo como jQuery.

Llámalo efecto de red si quieres. Esto no quiere decir que el código será superior en jQuery; solo que la naturaleza concisa del código hace que sea más fácil comprender la estructura general para los programadores de todos los niveles de habilidad, aunque solo sea porque hay más código funcional visible a la vez en el archivo que está viendo. En este sentido, 5 líneas de código son mejores que 10.

En resumen, veo los principales beneficios de jQuery como código conciso y ubicuidad.

Aquí hay una comparación si quiero aplicar el mismo atributo, por ejemplo, ocultar todos los elementos de la clase "my-class". Esta es una razón para usar 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';
}

Con jQuery ya tan popular, deberían haber hecho que document.querySelector () se comportara como $ (). En su lugar, document.querySelector () solo selecciona el primer elemento coincidente, lo que lo hace útil hasta la mitad.

como dice el sitio oficial: "jQuery: The Write Less, Do More, JavaScript Library"

intente traducir el siguiente código jQuery sin ninguna biblioteca

$("p.neat").addClass("ohmy").show("slow");

Creo que la verdadera respuesta es que jQuery se desarrolló mucho antes de querySelector/querySelectorAllestar disponible en todos los principales navegadores.

El lanzamiento inicial de jQuery fue en 2006 . De hecho, incluso jQuery no fue el primero en implementar los selectores CSS .

IE fue el último navegador en implementar querySelector/querySelectorAll. Su octava versión fue lanzada en 2009 .

Ahora, los selectores de elementos DOM ya no son el punto más fuerte de jQuery. Sin embargo, todavía tiene muchos beneficios bajo la manga, como accesos directos para cambiar el contenido css y html del elemento, animaciones, eventos vinculantes, ajax.

Antigua pregunta, pero media década después, vale la pena volver a visitarla. Aquí solo estoy discutiendo el aspecto del selector de jQuery.

document.querySelector[All]es compatible con todos los navegadores actuales, hasta IE8, por lo que la compatibilidad ya no es un problema. Tampoco he encontrado problemas de rendimiento para hablar (se suponía que era más lento que document.getElementById, pero mis propias pruebas sugieren que es un poco más rápido).

Por lo tanto, cuando se trata de manipular un elemento directamente, es preferible a jQuery.

Por ejemplo:

var element=document.querySelector('h1');
element.innerHTML='Hello';

es muy superior a:

var $element=$('h1');
$element.html('hello');

Para hacer cualquier cosa, jQuery tiene que ejecutar un centenar de líneas de código (una vez tracé un código como el anterior para ver qué estaba haciendo realmente jQuery con él). Esto es claramente una pérdida de tiempo para todos.

El otro costo significativo de jQuery es el hecho de que envuelve todo dentro de un nuevo objeto jQuery. Esta sobrecarga es particularmente derrochadora si necesita desenvolver el objeto nuevamente o usar uno de los métodos del objeto para tratar las propiedades que ya están expuestas en el elemento original.

Sin embargo, donde jQuery tiene una ventaja es en cómo maneja las colecciones. Si el requisito es establecer propiedades de múltiples elementos, jQuery tiene un eachmétodo incorporado que permite algo como esto:

var $elements=$('h2');  //  multiple elements
$elements.html('hello');

Hacerlo con Vanilla JavaScript requeriría algo como esto:

var elements=document.querySelectorAll('h2');
elements.forEach(function(e) {
    e.innerHTML='Hello';
});

que algunos encuentran desalentador.

Los selectores de jQuery también son ligeramente diferentes, pero los navegadores modernos (excluyendo IE8) no obtendrán muchos beneficios.

Como regla, advierto contra el uso de jQuery para nuevos proyectos:

• jQuery es una biblioteca externa que se suma a la sobrecarga del proyecto y a su dependencia de terceros.
• La función jQuery es muy costosa, en cuanto al procesamiento.
• jQuery impone una metodología que necesita ser aprendida y puede competir con otros aspectos de su código.
• jQuery tarda en exponer nuevas funciones en JavaScript.

Si nada de lo anterior importa, entonces haz lo que quieras. Sin embargo, jQuery ya no es tan importante para el desarrollo multiplataforma como solía serlo, ya que JavaScript y CSS modernos van mucho más allá de lo que solían ser.

Esto no menciona otras características de jQuery. Sin embargo, creo que ellos también necesitan una mirada más cercana.

$ ("# id") vs document.querySelectorAll ("# id")

El acuerdo es con la función $ (), crea una matriz y luego la divide por usted, pero con document.querySelectorAll () crea una matriz y debe dividirla.

Solo un comentario sobre esto, cuando se usa material design lite, jquery selector no devuelve la propiedad para el diseño de material por alguna razón.

Por:

<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>

Esto funciona:

document.querySelector('#myinputfield').parentNode.MaterialTextfield.change();

Esto no lo hace:

$('#myinputfield').parentNode.MaterialTextfield.change();