Kiedy używać Vanilla JavaScript vs. jQuery?

Poprawną odpowiedzią jest to, że będziesz Zawsze brać karę za wydajność, gdy używasz jQuery zamiast "zwykłego starego" rodzimego 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, które są zbyt nudne w sytuacji cross-browser (AJAX jest jednym z najlepszych przykładów) i wygładza niespójności między niezliczoną ilością dostępnych przeglądarek i zapewnia spójne API. Ułatwia również takie koncepcje jak łączenie łańcuchowe, implikowana iteracja itp., aby uprościć pracę nad grupami elementów razem.

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

-- Edited to encompass comments --

Jako, że komentarze są szybkie do zwrócenia uwagi (i zgadzam się w 100%) powyższe stwierdzenia odnoszą się do kod benchmarkingowy. "Natywne" rozwiązanie JavaScript (zakładając, że jest dobrze napisane) przewyższy rozwiązanie jQuery, które osiąga to samo w prawie każdym przypadku(chciałbym zobaczyć inny przykład). jQuery przyspiesza czas rozwoju, co jest znaczącą korzyścią, której nie chcę bagatelizować. Ułatwia łatwy do odczytania, łatwy do naśladowania kod, który jest więcej niż niektórzy programiści są w stanie stworzyć na własną rękę.

Moim zdaniem odpowiedź zależy od tego, co próbujesz to osiągnąć. Jeśli, jak założyłem na podstawie Twojego odniesienia do korzyści wydajnościowych, jesteś po najlepszej możliwej prędkości z aplikacji, to Korzystanie z jQuery wprowadza narzut za każdym razem, gdy dzwonisz $(). Jeśli chodzi o czytelność, spójność, kompatybilność między przeglądarkami itp., to z pewnością istnieją powody, aby faworyzować jQuery zamiast "natywnego" JavaScript.

Istnieje framework o nazwie... zgadnij co? Vanilla JS. Mam nadzieję, że rozumiesz dowcip... : D poświęca czytelność kodu dla wydajności... Porównując go z jQuery poniżej widać, że pobieranie DOM elementu przez ID jest prawie 35x szybsze. :)

Vanilla JS to szybki, lekki, wieloplatformowy framework do budowanie niesamowitych, potężnych aplikacji JavaScript.

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

Istnieje już akceptowana odpowiedź, ale wierzę, że żadna odpowiedź wpisana bezpośrednio tutaj nie może być wyczerpująca na liście natywnych metod/atrybutów javascript, które praktycznie gwarantują obsługę między przeglądarkami. W tym celu mogę przekierować cię do quirksmode:

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

Jest to chyba najbardziej wyczerpująca lista tego, co działa, a co nie działa w jakiej przeglądarce. Zwróć szczególną uwagę na sekcję DOM. To jest dużo do przeczytaj, 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 powiesiłem je na ścianie, aby na pierwszy rzut oka wiedzieć, co jest bezpieczne w użyciu i co wymaga hacków. W dzisiejszych czasach po prostu wygoogluję coś w stylu quirksmode parentNode compatibility, gdy mam wątpliwości.

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

Kiedy:

1. wiesz, że istnieje niezakłócona obsługa między przeglądarkami dla tego, co robisz, i
2. nie jest znacząco więcej kodu do wpisania, a
3. nie jest znacznie mniej czytelny, a
4. jesteś przekonany, że jQuery nie wybierze różnych implementacji opartych na przeglądarce, aby osiągnąć lepszą wydajność, to:

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

Edit : Ta odpowiedź dotyczy zarówno wybierając użycie jQuery ogólnie, a nie pomijając go, a także wybierając, czy używać vanilla JS wewnątrz jQuery. Wybór pomiędzy attr('id') a .id pochyla się na rzecz JS, podczas gdy wybór pomiędzy removeClass('foo') a .className = .className.replace( new Regexp("(?:^|\\s+)"+foo+"(?:\\s+|$)",'g'), '' ) pochyla się na rzecz jQuery.

Odpowiedzi innych skupiły się na szerokim pytaniu " jQuery vs. zwykły JS."Sądząc po twoim OP, myślę, że po prostu zastanawiasz się, kiedy lepiej jest użyć vanilla JS, jeśli już zdecydowałeś się użyć jQuery. Twój przykład jest doskonałym przykładem, kiedy powinieneś używać vanilla JS:

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

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

this.id.

Jest wolniejszy, ponieważ musisz uruchomić nowy obiekt JS, aby odzyskać atrybut jQuery way. Jeśli masz zamiar używać $(this) do wykonywania innych operacji, zapisz ten obiekt jQuery w zmiennej i z nim operuj. Jednak natknąłem się na wiele sytuacji, w których po prostu potrzebuję atrybutu z elementu (jak id lub src).

Czy są jakieś inne powszechne praktyki tak? Gdzie niektóre Javascript operacje mogą być realizowane łatwiejsze, bez wprowadzania jQuery do mieszanka. A może to rzadki przypadek? (z jQuery "Skrót" faktycznie wymagający więcej kodu)

Myślę, że najczęstszym przypadkiem jest ten, który opisujesz w swoim poście; ludzie niepotrzebnie owijają $(this) w obiekt jQuery. Widzę to najczęściej z id i value (zamiast $(this).val()).

Edytuj: tutaj jest artykuł, który wyjaśnia dlaczego używanie jQuery w przypadku attr() jest wolniejsze. Wyznanie: ukradłem to z tag wiki, ale myślę, że warto wspomnieć o pytanie.

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

Jeśli zależy Ci głównie na wydajności, twój główny przykład trafia w sedno. Niepotrzebnie lub redundantnie wywoływanie jQuery jest, IMHO, drugą główną przyczyną powolnego działania (pierwszą jest słaba TRAWERSACJA DOM).

To nie jest naprawdę przykład tego, czego szukasz, ale widzę to tak często, że można o tym wspomnieć: jednym z najlepszych sposobów na przyspieszenie wydajności skryptów jQuery jest buforowanie obiektów jQuery i / lub używanie ł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 na pewno jest nakładanie się JS i JQ. Kod, który pokazałeś, jest tego dobrym przykładem. Szczerze mówiąc, najlepszym powodem do używania JQ nad JS jest po prostu kompatybilność przeglądarki. Zawsze skłaniam się ku JQ, nawet jeśli mogę coś osiągnąć w JS.

To jest moje osobiste zdanie, ale ponieważ jQuery i tak jest JavaScript, myślę, że teoretycznie nie może działać lepiej niż vanilla js kiedykolwiek.

Ale praktycznie może działać lepiej niż ręcznie pisany js, ponieważ czyjś ręcznie pisany kod może nie być tak wydajny jak jQuery.

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

Lista aktywnych właściwości pierwszej odpowiedzi this jako elementu DOM jest całkiem kompletna.

Może zainteresować Cię również poznanie innych.

Gdy jest to dokument:

• this.forms Aby uzyskać HTMLCollection z obecnych formularzy dokumentów,
• this.anchors aby uzyskać HTMLCollection wszystkich HTMLAnchorElements z name ustawionych,
• this.links aby uzyskać HTMLCollection wszystkich HTMLAnchorElement S z href ustawionych,
• this.images aby uzyskać HTMLCollection wszystkich HTMLImageElement s
• i to samo dotyczy przestarzałych apletów jak this.applets

Kiedy pracujesz z document.forms, document.forms[formNameOrId] pobiera tak nazwany lub zidentyfikowany formularz.

Gdy jest to forma:

• 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 uczenie się już istniejących właściwości elementów HTML, do których dostęp jest tak szybki.

$(this) różni się od this:

Używając $(this) upewniasz się, że prototyp jQuery jest przekazywany do obiektu.

Jak zwykle spóźnię się na tę imprezę.

To nie była dodatkowa funkcjonalność, która sprawiła, że zdecydowałem się na użycie jQuery, tak atrakcyjne jak to było. W końcu nic nie powstrzymuje cię od pisania własnych funkcji.

To był fakt, że było tak wiele sztuczek, aby nauczyć się podczas modyfikowania DOM, aby uniknąć wycieków pamięci(mówię o Tobie IE). Mieć jeden centralny zasób, który zarządzał wszystkimi tego rodzaju problemami dla mnie, napisany przez ludzi, którzy byli o wiele lepszymi koderami JS niż kiedykolwiek będzie, który był nieustannie sprawdzany, poprawiany i testowany został zesłany przez Boga.

Wydaje mi się, że tego rodzaju podpada pod argument cross browser support/abstraction.

I oczywiście jQuery nie wyklucza użycia prostego JS, gdy go potrzebujesz. Zawsze wydawało mi się, że oboje doskonale ze sobą współpracują.

Oczywiście jeśli twoja przeglądarka nie jest obsługiwana przez jQuery lub obsługujesz środowisko low end (starszy telefon?), a następnie dużą .plik js może być problemem. Pamiętaj kiedy jQuery było małe?

Ale zwykle różnica w wydajności nie jest problemem. Musi być wystarczająco szybki. Ponieważ Gigaherce cykli procesora będą marnować się co sekundę, Jestem bardziej zainteresowany wydajnością moich koderów, jedynymi zasobami programistycznymi, które nie podwajają mocy co 18 miesięcy.

To powiedziało, że obecnie zajmuję się problemami z dostępnością i najwyraźniej.innerHTML jest trochę Nie Nie z tym. jQuery oczywiście zależy od .innerHTML, so teraz szukam ramy, która będzie zależeć 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 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, w rzeczywistości, Google nie zezwala jQuery w żadnym z ich kodu (ani reagować, ponieważ jest własnością Facebook), które może nie wiedzieć, dopóki ankieter mówi "Przepraszam, ale nie można używać jQuery, to nie jest na liście zatwierdzonych W Xyz Corporation". Vanilla JavaScript działa absolutnie wszędzie, za każdym razem, i nigdy nie daje ten problem. Jeśli polegasz na bibliotece tak masz szybkość i łatwość, ale tracisz uniwersalność.

Ponadto, mówiąc o wywiadach, drugą wadą jest to, że jeśli mówisz, że musisz użyć biblioteki do rozwiązania problemu JavaScript podczas quizu kodowego, to wychodzi na to, że nie rozumiesz problemu, co wygląda trochę źle. Podczas gdy jeśli rozwiążesz go w surowym JavaScript waniliowym, pokazuje to, że naprawdę rozumiesz i możesz rozwiązać każdą część problemu, który rzucają przed tobą.