Kiedy używać Vanilla JavaScript vs. jQuery?

Zauważyłem podczas monitorowania / próby odpowiedzi na najczęściej zadawane pytania dotyczące jQuery, że istnieją pewne praktyki z użyciem javascript zamiast jQuery, które faktycznie pozwalają ci pisać mniej i robić ... cóż taką samą ilość. I może również przynieść korzyści w zakresie wydajności.

Konkretny przykład

$(this) vs this

Wewnątrz zdarzenia kliknięcia odwołującego się do identyfikatora klikanych obiektów

jQuery

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

JavaScript

this.id;

Czy są jakieś inne popularne praktyki tego typu? Tam, gdzie pewne operacje Javascript można wykonać łatwiej, bez dodawania jQuery do miksu. Czy to rzadki przypadek? („skrótu” jQuery wymagającego więcej kodu)

EDYCJA: Chociaż doceniam odpowiedzi dotyczące jQuery vs. zwykła wydajność javascript, tak naprawdę szukam odpowiedzi bardziej ilościowych. Podczas korzystania z jQuery , przypadki, w których lepiej byłoby (czytelność / zwartość) używać zwykłego javascript zamiast używać $(). Oprócz przykładu podanego w moim pierwotnym pytaniu.

• this.id (jak wiesz)
• this.value(w większości typów danych wejściowych. tylko problemy, które znam, to IE, gdy a <select>nie ma valueustawionych właściwości swoich <option>elementów lub danych wejściowych radia w Safari).
• this.className aby uzyskać lub ustawić całą właściwość „class”
• this.selectedIndexprzeciwko a, <select>aby uzyskać wybrany indeks
• this.optionsprzeciw a, <select>aby uzyskać listę <option>elementów
• this.textprzeciwko, <option>aby uzyskać jego treść tekstową
• this.rowsprzeciwko, <table>aby uzyskać kolekcję <tr>elementów
• this.cellsprzeciw a, <tr>aby uzyskać jego komórki (td i th)
• this.parentNode uzyskać bezpośredniego rodzica
• this.checkedaby uzyskać sprawdzony stan checkbox Thanks @Tim Down
• this.selectedaby uzyskać wybrany stan option podziękowania @ Tim Down
• this.disabledaby uzyskać wyłączony stan input Thanks @Tim Down
• this.readOnlyaby uzyskać stan readOnly: input Thanks @Tim Down
• this.hrefprzeciwko <a>elementowi, aby uzyskaćhref
• this.hostnameprzeciwko <a>elementowi, aby uzyskać jego domenęhref
• this.pathnameprzeciwko <a>elementowi, aby uzyskać ścieżkę jegohref
• this.searchprzeciwko <a>elementowi, aby uzyskać jego kwerendęhref
• this.src przeciwko elementowi, w którym poprawne jest posiadanie src

... Myślę, że masz pomysł.

Będą chwile, kiedy wydajność będzie kluczowa. Na przykład, jeśli wykonujesz coś w pętli wiele razy, możesz porzucić jQuery.

Ogólnie możesz wymienić:

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

z:

Powyżej było źle sformułowane. getAttributenie jest zamiennikiem, ale pobiera wartość atrybutu wysłanego z serwera, a odpowiadająca mu setAttributewartość ustawi go. Niezbędne w niektórych przypadkach.

Poniższe zdania w pewnym sensie to obejmowały. Zobacz tę odpowiedź, aby uzyskać lepsze leczenie.

el.getAttribute('someName');

... aby uzyskać bezpośredni dostęp do atrybutu. Zauważ, że atrybuty nie są takie same jak właściwości (choć czasami się odbijają). Oczywiście, że setAttributeteż.

Załóżmy, że wystąpiła sytuacja, w której otrzymałeś stronę, na której musisz rozpakować wszystkie tagi określonego typu. Jest to krótkie i łatwe w jQuery:

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

Ale jeśli jest ich wiele, możesz zrobić trochę natywnego interfejsu API DOM:

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] );
}

Ten kod jest dość krótki, działa lepiej niż wersja jQuery i można go łatwo przekształcić w funkcję wielokrotnego użytku w osobistej bibliotece.

Może się wydawać, że mam nieskończoną pętlę z zewnętrzną z whilepowodu while(spans[0]), ale ponieważ mamy do czynienia z „listą na żywo”, jest ona aktualizowana, gdy wykonujemy parent.removeChild(span[0]);. Jest to całkiem sprytna funkcja, za którą tęsknimy podczas pracy z tablicą (lub obiektem podobnym do tablicy).

Prawidłowa odpowiedź jest taka, że zawsze będziesz ponosił obniżenie wydajności, gdy używasz jQuery zamiast „zwykłego” starego JavaScript. To dlatego, że jQuery jest biblioteką JavaScript. To nie jest jakaś wymyślna nowa wersja JavaScript.

Powodem, dla którego jQuery jest potężny, jest to, że sprawia, że ​​niektóre rzeczy są zbyt żmudne w sytuacji między przeglądarkami (AJAX jest jednym z najlepszych przykładów) i łagodzi niespójności między niezliczonymi dostępnymi przeglądarkami i zapewnia spójny interfejs API. Ułatwia także takie koncepcje, jak tworzenie łańcuchów, sugerowanie iteracji itp., Aby uprościć wspólną pracę nad grupami elementów.

Nauka jQuery nie zastąpi nauki JavaScript. Powinieneś mieć solidne podstawy w tym drugim, abyś w pełni docenił to, co znajomość tego pierwszego ułatwia ci.

- Edytowane w celu uwzględnienia komentarzy -

Ponieważ komentarze są szybkie do wskazania (i zgadzam się ze 100%), powyższe stwierdzenia odnoszą się do kodu testu porównawczego. „Natywne” rozwiązanie JavaScript (zakładając, że jest dobrze napisane) będzie lepsze niż rozwiązanie jQuery, które osiąga to samo w prawie każdym przypadku (chciałbym zobaczyć inny przykład). jQuery przyspiesza czas programowania, co jest znaczącą korzyścią, której nie zamierzam bagatelizować. Ułatwia łatwy do odczytania, łatwy do śledzenia kod, który jest więcej niż niektórzy programiści są w stanie stworzyć samodzielnie.

Moim zdaniem odpowiedź zależy od tego, co próbujesz osiągnąć. Jeśli, jak przypuszczałem na podstawie odwołania do korzyści z wydajności, dążysz do uzyskania najlepszej możliwej prędkości z aplikacji, to użycie jQuery wprowadza narzut za każdym razem, gdy dzwonisz $(). Jeśli zależy Ci na czytelności, spójności, kompatybilności z różnymi przeglądarkami itp., Z pewnością istnieją powody, aby faworyzować jQuery nad „rodzimym” JavaScript.

Istnieje framework o nazwie ... och, zgadnij co? Vanilla JS. Mam nadzieję, że masz żart ...: D Poświęca czytelność kodu dla wydajności ... Porównując go z jQueryponiższym, możesz zauważyć, że wyszukiwanie DOMelementu IDjest prawie 35 razy szybsze. :)

Więc jeśli chcesz wydajności, lepiej wypróbuj Vanilla JS i wyciągnij własne wnioski. Być może JavaScript nie zawiesi GUI przeglądarki / zablokuje wątek interfejsu podczas intensywnego kodu, takiego jak wewnątrz forpętli.

Vanilla JS to szybka, lekka, wieloplatformowa platforma do tworzenia niesamowitych, potężnych aplikacji JavaScript.

Na ich stronie głównej jest kilka porównań:

Odpowiedź jest już zaakceptowana, ale uważam, że żadna odpowiedź wpisana bezpośrednio tutaj nie może być wyczerpująca na liście natywnych metod / atrybutów javascript, które praktycznie gwarantowały obsługę wielu przeglądarek. W tym celu mogę skierować Cię do trybu quirksmode:

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

Jest to być może najbardziej wyczerpująca lista tego, co działa, a co nie działa w jakiejkolwiek przeglądarce. Zwróć szczególną uwagę na sekcję DOM. To dużo do przeczytania, ale nie chodzi o to, aby przeczytać wszystko, ale użyć go jako odniesienia.

Kiedy zacząłem poważnie pisać aplikacje internetowe, wydrukowałem wszystkie tabele DOM i zawiesiłem je na ścianie, aby na pierwszy rzut oka wiedzieć, co jest bezpieczne w użyciu, a co wymaga włamań. Obecnie po prostu szukam w Google czegoś quirksmode parentNode compatibility, co mam wątpliwości.

Jak wszystko inne, osąd jest głównie kwestią doświadczenia. Naprawdę nie polecałbym ci przeczytać całej strony i zapamiętać wszystkich problemów, aby dowiedzieć się, kiedy używać jQuery, a kiedy zwykłego JS. Pamiętaj tylko o liście. Wyszukiwanie jest dość łatwe. Z czasem rozwiniesz instynkt, kiedy preferowane jest zwykłe JS.

PS: PPK (autor strony) ma również bardzo fajną książkę, którą polecam przeczytać

Kiedy:

1. wiesz, że masz niezachwianą obsługę różnych przeglądarek tego, co robisz, i
2. nie jest znacznie więcej kodu do wpisania, oraz
3. nie jest znacznie mniej czytelny, oraz
4. masz wystarczającą pewność, że jQuery nie wybierze różnych implementacji opartych na przeglądarce, aby osiągnąć lepszą wydajność, a następnie:

użyj JavaScript. W przeciwnym razie użyj jQuery (jeśli możesz).

Edycja : Ta odpowiedź dotyczy zarówno wyboru ogólnego zastosowania jQuery, jak i pominięcia go, a także wyboru, czy używać JS waniliowego wewnątrz jQuery. Wybieranie pomiędzy attr('id')i .idpochylanie się na rzecz JS, przy jednoczesnym wybieraniu pomiędzy removeClass('foo')i .className = .className.replace( new Regexp("(?:^|\\s+)"+foo+"(?:\\s+|$)",'g'), '' )pochylanie się na korzyść jQuery.

Odpowiedzi innych koncentrowały się na szerokim pytaniu „jQuery vs. zwykły JS”. Sądząc z twojego OP, myślę, że po prostu zastanawiałeś się, kiedy lepiej użyć waniliowego JS, jeśli już zdecydowałeś się użyć jQuery. Twój przykład jest doskonałym przykładem tego, kiedy powinieneś używać waniliowej JS:

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

Jest wolniejszy i (moim zdaniem) mniej czytelny niż:

this.id.

Jest wolniejszy, ponieważ musisz rozłożyć nowy obiekt JS, aby pobrać atrybut w sposób jQuery. Teraz, jeśli zamierzasz $(this)wykonywać inne operacje, zapisz ten obiekt jQuery w zmiennej i działaj z nim. Jednak natknąłem się na wiele sytuacji, w których potrzebuję tylko atrybutu z elementu (jak idlub src).

Czy są jakieś inne popularne praktyki tego typu? Tam, gdzie pewne operacje Javascript można wykonać łatwiej, bez dodawania jQuery do miksu. Czy to rzadki przypadek? („skrótu” jQuery wymagającego więcej kodu)

Myślę, że najczęstszym przypadkiem jest ten opisany w poście; ludzie $(this)niepotrzebnie zawijają się w obiekcie jQuery. Widzę to najczęściej za pomocą idi value(zamiast tego $(this).val()).

Edytować: Oto artykuł, który wyjaśnia, dlaczego używanie jQuery w attr()przypadku jest wolniejsze. Spowiedź: ukradłem ją z tagu wiki, ale myślę, że warto wspomnieć o tym pytaniu.

Edytuj ponownie: Biorąc pod uwagę wpływ na czytelność / wydajność bezpośredniego dostępu do atrybutów, powiedziałbym, że dobrą zasadą jest prawdopodobnie próba użyciathis.<attributename> gdy to możliwe. Prawdopodobnie istnieją przypadki, w których to nie zadziała z powodu niespójności przeglądarki, ale prawdopodobnie lepiej wypróbować to najpierw i wrócić do jQuery, jeśli to nie działa.

Jeśli najbardziej martwisz się wydajnością, Twój główny przykład uderza w głowę. Niepotrzebne lub zbędne wywoływanie jQuery jest, IMHO, drugą główną przyczyną niskiej wydajności (pierwszą z nich jest słaba przemiana DOM).

To nie jest tak naprawdę przykład tego, czego szukasz, ale widzę to tak często, że trzeba wspomnieć: Jednym z najlepszych sposobów na przyspieszenie wydajności skryptów jQuery jest buforowanie obiektów jQuery i / lub użycie łańcucha:

// 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();

Odkryłem, że JS i JQ z pewnością się pokrywają. Kod, który pokazałeś, jest tego dobrym przykładem. Szczerze mówiąc, najlepszym powodem do korzystania z JQ nad JS jest po prostu kompatybilność przeglądarki. Zawsze pochylam się w kierunku JQ, nawet jeśli mogę coś osiągnąć w JS.

To jest mój osobisty pogląd, ale ponieważ jQuery i tak jest JavaScript, myślę, że teoretycznie nie może on działać lepiej niż waniliowy JS.

Ale praktycznie może działać lepiej niż ręcznie napisany JS, ponieważ odręczny kod może nie być tak wydajny jak jQuery.

Podsumowując - do mniejszych rzeczy zwykle używam waniliowej JS, do intensywnych projektów JS lubię używać jQuery i nie wymyślać koła - jest to również bardziej produktywne.

Lista właściwości aktywnych pierwszej odpowiedzi thisjako elementu DOM jest dość kompletna.

Interesujące może być również poznanie innych.

Gdy to jest dokument:

• this.forms dostać HTMLCollection aktualne formularze dokumentów,
• this.anchorsaby uzyskać HTMLCollectionwszystko HTMLAnchorElementsz nameustawieniem,
• this.linksaby uzyskać HTMLCollectionwszystkie HTMLAnchorElementzhref ustawieniem,
• this.imageszdobyć HTMLCollectionwszystkieHTMLImageElement s
• i to samo z przestarzałymi apletami jak this.applets

Podczas pracy z document.forms,document.forms[formNameOrId] dostaje tak nazwie lub zidentyfikowany formularza.

Gdy jest to formularz:

• this[inputNameOrId] aby uzyskać tak nazwane lub zidentyfikowane pole

Gdy jest to pole formularza:

• this.type aby uzyskać typ pola

Ucząc się selektorów jQuery, często pomijamy naukę już istniejących właściwości elementów HTML, do których dostęp jest tak szybki.

Jak zwykle spóźniam się na to przyjęcie.

To nie dodatkowa funkcjonalność sprawiła, że ​​zdecydowałem się na użycie jQuery, choć było to tak atrakcyjne. W końcu nic nie powstrzymuje Cię przed pisaniem własnych funkcji.

Faktem było, że było tak wiele sztuczek do nauczenia się podczas modyfikowania DOM, aby uniknąć wycieków pamięci (mówię o tobie IE). Posiadanie jednego centralnego zasobu, który zarządzałby dla mnie wszystkimi tego typu problemami, napisanego przez ludzi, którzy byli o wiele lepszymi programistami JS niż kiedykolwiek będę, który był stale sprawdzany, poprawiany i testowany, to był bóg.

Wydaje mi się, że ten rodzaj mieści się w argumencie wsparcia / abstrakcji między przeglądarkami.

I oczywiście jQuery nie wyklucza użycia prostej JS, gdy jej potrzebujesz. Zawsze czułem, że ta dwójka wydaje się bezproblemowo ze sobą współpracować.

Oczywiście, jeśli twoja przeglądarka nie jest obsługiwana przez jQuery lub wspierasz środowisko niższej klasy (starszy telefon?), Problem może stanowić duży plik .js. Pamiętasz, kiedy jQuery było małe?

Ale zwykle różnica w wydajności nie stanowi problemu. Musi być tylko wystarczająco szybki. Ponieważ Gigahertz cykli procesora marnuje się co sekundę, bardziej martwię się wydajnością moich koderów, jedynych zasobów programistycznych, które nie podwoją mocy co 18 miesięcy.

To powiedziawszy, że obecnie szukam problemów z dostępnością i najwyraźniej .innerHTML jest trochę nie z tym. jQuery oczywiście zależy od .innerHTML, więc teraz szukam frameworka, który będzie zależał od nieco żmudnych metod, które są dozwolone. I mogę sobie wyobrazić, że taki framework będzie działał wolniej niż jQuery, ale dopóki będzie on działał wystarczająco dobrze, będę szczęśliwy.

Oto nietechniczna odpowiedź - wiele zadań może nie zezwalać na niektóre biblioteki, takie jak jQuery.

W rzeczywistości Google nie zezwala na stosowanie jQuery w żadnym z ich kodów (ani React, ponieważ jest własnością Facebooka), czego możesz nie znać, dopóki ankieter nie powie „Przepraszam, ale nie możesz użyć jQuery, nie jest włączony zatwierdzona lista w XYZ Corporation ”. Waniliowy JavaScript działa absolutnie wszędzie i za każdym razem i nigdy nie spowoduje tego problemu. Jeśli polegasz na bibliotece, tak, zyskujesz szybkość i łatwość, ale tracisz uniwersalność.

Poza tym, mówiąc o przeprowadzaniu wywiadów, drugą wadą jest to, że jeśli mówisz, że musisz użyć biblioteki, aby rozwiązać problem JavaScript podczas quizu kodowego, okazuje się, że tak naprawdę nie rozumiesz problemu, który wygląda trochę źle. Natomiast jeśli rozwiążesz go za pomocą surowego waniliowego JavaScript, pokaże to, że faktycznie rozumiesz i możesz rozwiązać każdą część problemu, który ci rzucają.

$(this) jest inny niż this :

Używając tego $(this)masz pewność, że prototyp jQuery jest przekazywany na obiekt.