jQuery vs document.querySelectorAll

Ouvi várias vezes que o ativo mais forte do jQuery é a maneira como ele consulta e manipula elementos no DOM: você pode usar consultas CSS para criar consultas complexas que seriam muito difíceis de executar em javascript regular. No entanto, tanto quanto eu sei, você pode obter o mesmo resultado com document.querySelectorou document.querySelectorAll, que são suportados no Internet Explorer 8 e superior.

Portanto, a pergunta é a seguinte: por que 'arriscar' a sobrecarga do jQuery se seu ativo mais forte pode ser alcançado com JavaScript puro?

Eu sei que o jQuery tem mais do que apenas seletores CSS, por exemplo, AJAX entre navegadores, bom evento anexando etc. Mas sua parte de consulta é uma parte muito grande da força do jQuery!

Alguma ideia?

document.querySelectorAll() possui várias inconsistências nos navegadores e não é suportado em navegadores antigos. ^{Isso provavelmente não causará mais problemas atualmente} . Ele tem um mecanismo de escopo muito pouco intuitivo e alguns outros recursos não tão agradáveis . Além disso, com o javascript, é mais difícil trabalhar com os conjuntos de resultados dessas consultas, o que em muitos casos você pode querer fazer. jQuery fornece funções para trabalhar com eles como: filter(), find(), children(), parent(), map(), not()e vários outros. Sem mencionar a capacidade do jQuery de trabalhar com seletores de pseudo-classe.

No entanto, eu não consideraria essas coisas como os recursos mais fortes do jQuery, mas outras como "trabalhar" no dom (eventos, estilo, animação e manipulação) de maneira compatível com o navegador cruzado ou na interface ajax.

Se você deseja apenas o mecanismo seletor do jQuery, pode usar o que o próprio jQuery está usando: Sizzle Dessa forma, você tem o poder do mecanismo jQuerys Selector sem a sobrecarga desagradável.

Edição: Apenas para o registro, eu sou um grande fã de JavaScript baunilha. No entanto, é verdade que às vezes você precisa de 10 linhas de JavaScript, onde escreveria uma linha jQuery.

É claro que você precisa ser disciplinado para não escrever o jQuery assim:

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

Isso é extremamente difícil de ler, enquanto o último é bem claro:

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

O JavaScript equivalente seria muito mais complexo, ilustrado pelo pseudocódigo acima:

1) Encontre o elemento, considere pegar todo o elemento ou apenas o primeiro.

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

2) Itere a matriz de nós filhos através de alguns loops (possivelmente aninhados ou recursivos) e verifique a classe (a lista de classes não está disponível em todos os 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) aplique o estilo css

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

Esse código seria pelo menos duas vezes mais linhas de código que você escreve com o jQuery. Além disso, você deve considerar problemas entre navegadores que comprometam a grande vantagem de velocidade (além da confiabilidade) do código nativo.

Se você estiver otimizando sua página para o IE8 ou mais recente, considere realmente se precisa de jquery ou não. Navegadores modernos têm muitos recursos nativamente fornecidos pelo jquery.

Se você gosta de desempenho, pode obter benefícios incríveis de desempenho (2-10 mais rápido) usando javascript nativo: http://jsperf.com/jquery-vs-native-selector-and-element-style/2

Transformei um div-tagcloud de jquery em javascript nativo (compatível com IE8 +), os resultados são impressionantes. 4 vezes mais rápido com um pouco de sobrecarga.

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

Você pode não precisar do Jquery fornece uma visão geral muito boa, quais métodos nativos substituem para qual versão do navegador.

http://youmightnotneedjquery.com/

Apêndice: Comparações mais rápidas de como os métodos nativos competem com o jquery

• Array: $ .inArray vs Array.indexDe Jquery 24% mais lento

• DOM: $ .empty vs Node.innerHtml: Jquery 97% mais lento

• DOM: $ .on vs Node.addEventListener: Jquery 90% mais lento

• DOM: $ .find vs Node.queryselectorall: Jquery 90% mais lento

• Matriz: $ .grep vs Matriz.filtro: nativo 70% mais lento

• DOM: $ .show / hide vs display none: Jquery 85% mais lento

• AJAX: $ .ajax vs XMLHttpRequest: Jquery 89% mais lento

• Altura: $ .outerHeight vs offsetHeight: Jquery 87% mais lento

• Atributo: $ .attr vs setAttribute: Jquery 86% mais lento

Para entender por que o jQuery é tão popular, é importante entender de onde viemos!

Cerca de uma década atrás, os principais navegadores eram IE6, Netscape 8 e Firefox 1.5. Naquela época, havia poucas maneiras entre navegadores para selecionar um elemento do DOM além Document.getElementById().

Então, quando o jQuery foi lançado em 2006 , foi bastante revolucionário. Naquela época, o jQuery definia o padrão de como selecionar / alterar facilmente elementos HTML e acionar eventos, porque sua flexibilidade e suporte ao navegador eram sem precedentes.

Agora, mais de uma década depois, muitos recursos que tornaram o jQuery tão popular foram incluídos no padrão javaScript:

• Em vez de jQuery $(), agora você pode usarDocument.querySelectorAll()
• Em vez de jQuery $el.on(), agora você pode usarEventTarget.addEventListener()
• Em vez de jQuery $el.toggleClass(), agora você pode usarElement.classList.toggle()
• ...

Geralmente, eles não estavam disponíveis em 2005. O fato de estarem hoje obviamente implora a questão de por que deveríamos usar o jQuery. E, de fato, as pessoas estão cada vez mais se perguntando se devemos usar o jQuery .

Portanto, se você acha que entende JavaScript bem o suficiente para não usar o jQuery, por favor! Não se sinta obrigado a usar o jQuery, apenas porque muitos outros estão fazendo isso!

Isso porque o jQuery pode fazer muito mais do que querySelectorAll.

Primeiro, o jQuery (e o Sizzle, em particular), funciona para navegadores mais antigos, como o IE7-8, que não suporta seletores CSS2.1-3.

Além disso, o Sizzle (que é o mecanismo de seleção por trás do jQuery) oferece muitos instrumentos seletores mais avançados, como a :selectedpseudo-classe, um :not()seletor avançado , uma sintaxe mais complexa, como $("> .children")por exemplo.

E ele faz a navegação entre navegadores, na perfeição, oferecendo tudo o que o jQuery pode oferecer (plugins e APIs).

Sim, se você acha que pode confiar em seletores simples de classe e ID, o jQuery é demais para você e você pagaria um pagamento exagerado. Mas se não, e quiser tirar proveito de toda a bondade do jQuery, use-o.

O mecanismo seletor Sizzle do jQuery pode usar querySelectorAll se disponível. Ele também suaviza as inconsistências entre os navegadores para obter resultados uniformes. Se você não quiser usar todo o jQuery, poderá usar o Sizzle separadamente. Esta é uma roda bastante fundamental para inventar.

Aqui estão algumas escolhas da fonte que mostram o tipo de coisa que o jQuery (com Sizzle) classifica para você:

Modo peculiaridades do 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;
    }

Se esse guarda falhar, ele usa uma versão do Sizzle que não é aprimorada querySelectorAll. Mais abaixo, existem identificadores específicos para inconsistências no IE, Opera e no 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 );
  }

E se tudo mais falhar, retornará o resultado de oldSizzle(query, context, extra, seed).

Em termos de manutenção de código, há vários motivos para manter uma biblioteca amplamente usada.

Uma das principais é que elas estão bem documentadas e têm comunidades como ... digamos ... stackexchange, onde é possível encontrar ajuda com as bibliotecas. Com uma biblioteca codificada personalizada, você tem o código-fonte e talvez um documento de instruções, a menos que o (s) codificador (es) gastem mais tempo documentando o código do que escrevendo, o que é extremamente raro.

Escrever sua própria biblioteca pode funcionar para você , mas o estagiário sentado na mesa ao lado pode ter mais facilidade em se familiarizar com algo como jQuery.

Chame isso de efeito de rede, se quiser. Isso não quer dizer que o código seja superior no jQuery; apenas que a natureza concisa do código facilita a compreensão da estrutura geral para programadores de todos os níveis, mesmo que haja mais código funcional visível ao mesmo tempo no arquivo que você está visualizando. Nesse sentido, 5 linhas de código são melhores que 10.

Para resumir, vejo os principais benefícios do jQuery como sendo código conciso e onipresença.

Aqui está uma comparação se eu quiser aplicar o mesmo atributo, por exemplo, ocultar todos os elementos da classe "minha classe". Esse é um dos motivos para usar o 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';
}

Com o jQuery já tão popular, eles deveriam ter feito document.querySelector () se comportar como $ (). Em vez disso, document.querySelector () seleciona apenas o primeiro elemento correspondente, o que o torna apenas parcialmente útil.

como diz o site oficial: "jQuery: escreva menos, faça mais, biblioteca JavaScript"

tente traduzir o seguinte código jQuery sem nenhuma biblioteca

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

Eu acho que a verdadeira resposta é que o jQuery foi desenvolvido muito antes querySelector/querySelectorAll se tornar disponível em todos os principais navegadores.

O lançamento inicial do jQuery foi em 2006 . De fato, nem o jQuery foi o primeiro a implementar seletores de CSS .

O IE foi o último navegador a implementar querySelector/querySelectorAll. Sua 8ª versão foi lançada em 2009 .

Portanto, agora, os seletores de elementos DOM não são mais o ponto mais forte do jQuery. No entanto, ele ainda tem muitas novidades na manga, como atalhos para alterar o conteúdo css e html do elemento, animações, associação de eventos e ajax.

Pergunta antiga, mas meia década depois, vale a pena revisar. Aqui estou discutindo apenas o aspecto seletor do jQuery.

document.querySelector[All]é suportado por todos os navegadores atuais, até o IE8, portanto, a compatibilidade não é mais um problema. Também não encontrei problemas de desempenho para falar (era para ser mais lento do que document.getElementById, mas meus próprios testes sugerem que é um pouco mais rápido).

Portanto, quando se trata de manipular um elemento diretamente, é preferível ao jQuery.

Por exemplo:

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

é muito superior a:

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

Para fazer qualquer coisa, o jQuery precisa percorrer uma centena de linhas de código (uma vez rastreiei um código como o acima para ver o que o jQuery estava realmente fazendo com ele). Isso é claramente uma perda de tempo de todos.

O outro custo significativo do jQuery é o fato de envolver tudo dentro de um novo objeto jQuery. Essa sobrecarga é particularmente inútil se você precisar desembrulhar o objeto novamente ou usar um dos métodos do objeto para lidar com propriedades que já estão expostas no elemento original.

Onde o jQuery tem uma vantagem, no entanto, é como ele lida com coleções. Se o requisito é definir propriedades de vários elementos, o jQuery possui um eachmétodo interno que permite algo como isto:

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

Para fazer isso com o Vanilla JavaScript seria necessário algo como isto:

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

que alguns acham assustador.

Os seletores de jQuery também são um pouco diferentes, mas os navegadores modernos (excluindo o IE8) não terão muitos benefícios.

Como regra, eu aviso contra o uso do jQuery para novos projetos:

• O jQuery é uma biblioteca externa que contribui para a sobrecarga do projeto e para a sua dependência de terceiros.
• A função jQuery é muito cara, em termos de processamento.
• O jQuery impõe uma metodologia que precisa ser aprendida e pode competir com outros aspectos do seu código.
• O jQuery demora a expor novos recursos em JavaScript.

Se nenhuma das opções acima importa, faça o que quiser. No entanto, o jQuery não é mais tão importante para o desenvolvimento em várias plataformas como costumava ser, pois o JavaScript e o CSS modernos vão muito além do que costumavam ser.

Isso não menciona outros recursos do jQuery. No entanto, acho que eles também precisam de um olhar mais atento.

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

O negócio é com a função $ () que cria uma matriz e depois a divide para você, mas com document.querySelectorAll () ele cria uma matriz e você precisa dividi-la.

Apenas um comentário sobre isso, ao usar o material design lite, o seletor jquery não retorna a propriedade para o design do material por algum motivo.

Para:

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

Isso funciona:

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

Isto não:

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