jQuery a document.querySelectorAll

Kilkakrotnie słyszałem, że najsilniejszym atutem jQuery jest sposób, w jaki wykonuje zapytania i manipuluje elementami w DOM: możesz używać zapytań CSS do tworzenia złożonych zapytań, które byłyby bardzo trudne do wykonania w zwykłym javascript. Jednak o ile wiem, ten sam wynik można osiągnąć za pomocą document.querySelectorlub document.querySelectorAll, które są obsługiwane w przeglądarce Internet Explorer 8 i nowszych.

Zatem pytanie brzmi: po co „ryzykować” narzut jQuery, skoro jego najsilniejszy atut można osiągnąć za pomocą czystego JavaScript?

Wiem, że jQuery ma więcej niż tylko selektory CSS, na przykład AJAX między przeglądarkami, fajne dołączanie zdarzeń itp. Ale jego część z zapytaniami jest bardzo dużą częścią siły jQuery!

jakieś pomysły?

document.querySelectorAll() ma kilka niespójności między przeglądarkami i nie jest obsługiwany w starszych przeglądarkach ^{To prawdopodobnie nie będzie już powodować żadnych problemów w dzisiejszych czasach} . Ma bardzo nieintuicyjny mechanizm określania zakresu i kilka innych niezbyt przyjemnych funkcji . Również w przypadku javascript praca z zestawami wyników tych zapytań jest trudniejsza, co w wielu przypadkach możesz chcieć zrobić. jQuery udostępnia funkcje do pracy nad nimi jak: filter(), find(), children(), parent(), map(), not()i kilka innych. Nie wspominając o zdolności jQuery do pracy z selektorami pseudoklas.

Jednak nie uważałbym tych rzeczy za najsilniejsze cechy jQuery, ale inne rzeczy, takie jak „praca” nad domem (zdarzenia, stylizacja, animacja i manipulacja) w sposób zgodny z różnymi przeglądarkami lub interfejs Ajax .

Jeśli chcesz tylko silnika selektora z jQuery, możesz użyć tego, którego używa jQuery: Sizzle W ten sposób masz moc silnika jQuerys Selector bez przykrych kosztów.

EDYCJA: Tak dla przypomnienia, jestem wielkim fanem waniliowego JavaScript. Niemniej jednak faktem jest, że czasami potrzebujesz 10 linii JavaScript, w których możesz napisać 1 wiersz jQuery.

Oczywiście trzeba być zdyscyplinowanym, aby nie pisać jQuery w ten sposób:

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

Jest to niezwykle trudne do odczytania, podczas gdy to drugie jest całkiem jasne:

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

Równoważny JavaScript byłby znacznie bardziej złożony, co ilustruje powyższy pseudokod:

1) Znajdź element, rozważ wzięcie całego elementu lub tylko pierwszego.

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

2) Iteruj po tablicy węzłów potomnych za pomocą niektórych (prawdopodobnie zagnieżdżonych lub rekurencyjnych) pętli i sprawdź klasę (lista klas nie jest dostępna we wszystkich przeglądarkach!)

//.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) zastosuj styl css

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

Ten kod byłby co najmniej dwa razy większy niż wiersze kodu, które piszesz za pomocą jQuery. Należy również wziąć pod uwagę problemy z różnymi przeglądarkami, które mogą zagrozić znacznej przewadze szybkości (poza niezawodnością) kodu natywnego.

Jeśli optymalizujesz swoją stronę dla IE8 lub nowszej wersji, powinieneś naprawdę rozważyć, czy potrzebujesz jquery, czy nie. Nowoczesne przeglądarki mają wiele zasobów natywnie dostarczanych przez jquery.

Jeśli zależy Ci na wydajności, możesz uzyskać niesamowite korzyści w zakresie wydajności (2-10 szybciej), używając natywnego javascript: http://jsperf.com/jquery-vs-native-selector-and-element-style/2

Przekształciłem div-tagcloud z jquery na natywny javascript (kompatybilny z IE8 +), wyniki są imponujące. 4 razy szybciej przy niewielkim obciążeniu.

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

You Might Not Need Jquery zapewnia naprawdę przyjemny przegląd, w którym metody natywne zastępują daną wersję przeglądarki.

http://youmightnotneedjquery.com/

Dodatek: Dalsze porównania szybkości, w jaki sposób metody natywne konkurują z jQuery

• Array: $ .inArray vs Array.indexOf: Jquery 24% wolniej

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

• DOM: $ .on vs Node.addEventListener: Jquery o 90% wolniej

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

• Array: $ .grep vs Array.filter: Native 70% wolniej

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

• AJAX: $ .ajax vs XMLHttpRequest: Jquery 89% wolniej

• Height: $ .outerHeight vs offsetHeight: Jquery 87% wolniej

• Attr: $ .attr vs setAttribute: Jquery 86% wolniej

Aby zrozumieć, dlaczego jQuery jest tak popularny, ważne jest, aby zrozumieć, skąd pochodzimy!

Około dekady temu najpopularniejszymi przeglądarkami były IE6, Netscape 8 i Firefox 1.5. W tamtych czasach poza tym nie było wielu sposobów wybierania elementu z DOM w różnych przeglądarkach Document.getElementById().

Tak więc, kiedy jQuery został wydany w 2006 roku , był całkiem rewolucyjny. Wtedy jQuery wyznaczyło standard łatwego wybierania / zmiany elementów HTML i wyzwalania zdarzeń, ponieważ jego elastyczność i obsługa przeglądarki były bezprecedensowe.

Teraz, ponad dziesięć lat później, wiele funkcji, które sprawiły, że jQuery stało się tak popularne, zostało włączonych do standardu javaScript:

• Zamiast jQuery $()możesz teraz używaćDocument.querySelectorAll()
• Zamiast jQuery $el.on()możesz teraz używaćEventTarget.addEventListener()
• Zamiast jQuery $el.toggleClass()możesz teraz używaćElement.classList.toggle()
• ...

Nie były one ogólnie dostępne w 2005 roku. Fakt, że są dzisiaj, oczywiście nasuwa pytanie, dlaczego w ogóle powinniśmy używać jQuery. I rzeczywiście, ludzie coraz częściej zastanawiają się, czy w ogóle powinniśmy używać jQuery .

Więc jeśli myślisz, że rozumiesz JavaScript na tyle dobrze, aby obejść się bez jQuery, zrób to! Nie czuj się zmuszony do korzystania z jQuery tylko dlatego, że robi to tak wielu innych!

Dzieje się tak, ponieważ jQuery może znacznie więcej niż querySelectorAll.

Przede wszystkim jQuery (aw szczególności Sizzle) działa w starszych przeglądarkach, takich jak IE7-8, które nie obsługują selektorów CSS2.1-3.

Ponadto Sizzle (który jest silnikiem selektora stojącym za jQuery) oferuje wiele bardziej zaawansowanych instrumentów selektora, takich jak :selectedpseudoklasa, zaawansowany :not()selektor, bardziej złożoną składnię, taką jak in $("> .children")i tak dalej.

I robi to bezbłędnie na różnych przeglądarkach, oferując wszystko, co może zaoferować jQuery (wtyczki i API).

Tak, jeśli myślisz, że możesz polegać na prostych selektorach klas i identyfikatorów, jQuery to dla Ciebie za dużo i zapłacisz przesadną zapłatę. Ale jeśli tego nie robisz i chcesz wykorzystać wszystkie zalety jQuery, użyj go.

Silnik selektora Sizzle jQuery może użyć, querySelectorAlljeśli jest dostępny. Wygładza również niespójności między przeglądarkami, aby uzyskać jednolite wyniki. Jeśli nie chcesz używać całego jQuery, możesz po prostu osobno użyć Sizzle. To dość fundamentalne koło do wymyślenia.

Oto kilka propozycji ze źródła, które pokazują, jakie rzeczy sortuje dla Ciebie jQuery (w / Sizzle):

Tryb dziwactwa 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;
    }

Jeśli ten strażnik zawiedzie, użyje wersji Sizzle, która nie jest ulepszona querySelectorAll. W dalszej części znajdują się specyficzne uchwyty niespójności w IE, Operze i przeglądarce 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 );
  }

A jeśli wszystko inne zawiedzie, zwróci wynik oldSizzle(query, context, extra, seed).

Jeśli chodzi o łatwość utrzymania kodu, istnieje kilka powodów, dla których warto trzymać się powszechnie używanej biblioteki.

Jedną z głównych jest to, że są dobrze udokumentowane i mają społeczności takie jak ... powiedzmy ... stackexchange, gdzie można znaleźć pomoc przy bibliotekach. Dzięki niestandardowej bibliotece kodowanej masz kod źródłowy i być może dokument instruktażowy, chyba że programiści spędzili więcej czasu na dokumentowaniu kodu niż na jego pisaniu, co jest rzadkością.

Pisanie własnej biblioteki może Ci pomóc pomóc, ale stażysta siedzący przy sąsiednim biurku może mieć łatwiejsze opanowanie czegoś takiego jak jQuery.

Nazwij to efektem sieci, jeśli chcesz. Nie oznacza to, że kod będzie lepszy w jQuery; tylko dlatego, że zwięzły charakter kodu ułatwia zrozumienie ogólnej struktury programistom na wszystkich poziomach umiejętności, choćby dlatego, że w przeglądanym pliku jest widocznych od razu więcej funkcjonalnego kodu. W tym sensie 5 linii kodu jest lepsze niż 10.

Podsumowując, widzę główne zalety jQuery jako zwięzły kod i wszechobecność.

Oto porównanie, jeśli chcę zastosować ten sam atrybut, np. Ukryć wszystkie elementy klasy „moja-klasa”. To jeden z powodów, dla których warto używać 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';
}

Z jQuery już tak popularnym, powinni byli sprawić, by document.querySelector () zachowywała się tak jak $ (). Zamiast tego document.querySelector () wybiera tylko pierwszy pasujący element, co czyni go użytecznym tylko w połowie.

jak mówi oficjalna strona: „jQuery: pisz mniej, rób więcej, biblioteka JavaScript”

spróbuj przetłumaczyć następujący kod jQuery bez żadnej biblioteki

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

Myślę, że prawdziwa odpowiedź jest taka, że ​​jQuery zostało opracowane dużo wcześniej querySelector/querySelectorAll udostępnieniem go we wszystkich głównych przeglądarkach.

Pierwsze wydanie jQuery miało miejsce w 2006 roku . W rzeczywistości nawet jQuery nie był pierwszym, który zaimplementował selektory CSS .

IE była ostatnią implementowaną przeglądarkąquerySelector/querySelectorAll . Jego ósma wersja została wydana w 2009 roku .

Więc teraz selektory elementów DOM nie są już najmocniejszą stroną jQuery. Jednak wciąż ma wiele dodatków w rękawie, takich jak skróty do zmiany zawartości css i html elementu, animacje, powiązanie zdarzeń, ajax.

Stare pytanie, ale pół dekady później warto do niego wrócić. Tutaj omawiam tylko aspekt selektora jQuery.

document.querySelector[All]jest obsługiwany przez wszystkie obecne przeglądarki, aż do IE8, więc kompatybilność nie jest już problemem. Nie znalazłem również żadnych problemów z wydajnością, o których mógłbym mówić (miał być wolniejszy niż document.getElementById, ale moje własne testy sugerują, że jest nieco szybszy).

Dlatego jeśli chodzi o bezpośrednie manipulowanie elementem, powinien być preferowany niż jQuery.

Na przykład:

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

jest znacznie lepszy:

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

Aby w ogóle cokolwiek zrobić, jQuery musi przejść przez sto linii kodu (kiedyś prześledziłem kod, taki jak powyższy, aby zobaczyć, co właściwie jQuery z nim robi). To z pewnością strata czasu dla wszystkich.

Innym znaczącym kosztem jQuery jest to, że opakowuje wszystko w nowy obiekt jQuery. Ten narzut jest szczególnie marnotrawny, jeśli musisz ponownie rozpakować obiekt lub użyć jednej z metod obiektu, aby poradzić sobie z właściwościami, które są już widoczne w oryginalnym elemencie.

Jednak zaletą jQuery jest sposób, w jaki obsługuje kolekcje. Jeśli wymaganiem jest ustawienie właściwości wielu elementów, jQuery ma wbudowaną eachmetodę, która pozwala na coś takiego:

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

Aby to zrobić z Vanilla JavaScript wymagałoby czegoś takiego:

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

co niektórzy uważają za zniechęcające.

Selektory jQuery również są nieco inne, ale nowoczesne przeglądarki (z wyjątkiem IE8) nie przyniosą większych korzyści.

Z reguły odradzam używanie jQuery do nowych projektów:

• jQuery to zewnętrzna biblioteka dodająca do kosztów ogólnych projektu i do Twojej zależności od stron trzecich.
• Funkcja jQuery jest bardzo droga, jeśli chodzi o przetwarzanie.
• jQuery narzuca metodologię, której należy się nauczyć i która może konkurować z innymi aspektami kodu.
• jQuery wolno udostępnia nowe funkcje w JavaScript.

Jeśli żadne z powyższych nie ma znaczenia, rób, co chcesz. Jednak jQuery nie jest już tak ważny dla tworzenia aplikacji wieloplatformowych, jak kiedyś, ponieważ nowoczesny JavaScript i CSS idą o wiele dalej niż kiedyś.

Nie wspomina się o innych cechach jQuery. Myślę jednak, że oni również potrzebują bliższego przyjrzenia się.

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

Umowa polega na tym, że funkcja $ () tworzy tablicę, a następnie dzieli ją za Ciebie, ale za pomocą funkcji document.querySelectorAll () tworzy tablicę i musisz ją podzielić.

Tylko komentarz na ten temat, gdy używasz Material Design Lite, selektor jQuery z jakiegoś powodu nie zwraca właściwości Material Design.

Dla:

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

To działa:

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

To nie:

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