Zalety używania czystego JavaScript w porównaniu z JQuery

86

Jakie są zalety korzystania tylko z języka JavaScript w porównaniu z używaniem tylko JQuery?

Mam ograniczone doświadczenie w kodowaniu JavaScript i JQuery. Dodałem bity i fragmenty każdej ze stron HTML, ale głównie kodowałem rzeczy po stronie serwera w innych językach. Zauważyłem, że chociaż teoretycznie możesz robić te same rzeczy przy użyciu jednego z dwóch podejść (i oczywiście możesz nawet pomieszać je w tym samym projekcie), wydaje się, że istnieje tendencja do korzystania z JQuery od samego początku bez względu na wymagania projektu.

Zastanawiam się więc, czy są jakieś punktualne korzyści z tego, że nie używam tylko JQuery, ale zamiast tego używam zwykłego, starego JavaScript?

Wiem, że to wygląda jak pytanie, ponieważ można powiedzieć, że „nie ma jednoznacznej odpowiedzi” lub „można to zawsze omawiać”, ale tak naprawdę liczę na punktualne odpowiedzi, takie jak „Możesz to zrobić w jedno podejście, a drugiego nie da się zrobić ”.


Zgodnie z komentarzem scrwtp, nie odnoszę się tylko do części dotyczącej obsługi DOM. Moje pytanie brzmi raczej: JQuery jest biblioteką. Dla Javascript. To, co wydaje mi się dziwne w tej bibliotece, w przeciwieństwie do innych bibliotek dla innych języków, to to, że w przypadku JQyery wydaje się, że została zaprojektowana tak, aby mogła z niej korzystać wyłącznie i nie musiała dotykać bezpośrednio Javascript. Jest to przeciwieństwo, powiedzmy, Hibernacji i SQL, gdzie chociaż biblioteka (lub raczej framework w tym przypadku, ale myślę, że analogia nadal ma zastosowanie) przejmuje wiele aspektów, nadal możesz używać SQL podczas korzystania z niego , przynajmniej w niektórych przypadkach z marginesami. Jednak w przypadku JQuery i JavaScript możesz robić wszystko, co robisz za pomocą Javascript, używając tylko JQuery (a przynajmniej tak mi się wydaje).


Zgodnie z komentarzem Stargazer712: tak, zgadzam się z tobą, pytanie brzmi, ponieważ określasz to jako „tylko kwestię tego, jak będziesz używać JavaScript”. Właśnie o to prosiłem, ale zrobiłem złe sformułowania. Oto kolejna analogia: Spring Expression Language. To biblioteka Java. Nie możesz używać go bez Javy, jest on oparty na Javie, a przez to wszystko, co nadal możesz używać Javy. Ale w praktyce to, co możesz zrobić, to dodać tę bibliotekę do projektu Java, a następnie napisać cały kod za pomocą języka wyrażeń Spring EL, co skutecznie sprawia, że ​​Twój kod wcale nie przypomina Java, a nawet zmienia paradygmat (na przykład nie masz już silne wymuszanie typu podczas korzystania z tego). Chociaż rozumiem, że JQuery jest tylko biblioteką JS, wydaje mi się, że w praktyce ma taki sam efekt jak Spring EL w Javie, tzn. Możesz używać jego interfejsów API tylko w projekcie i unikać interfejsów API JavaScript. Zastanawiałem się, czy to dobrze zrobić, jakie mogą być pułapki itp.

(i tak, po przeczytaniu odpowiedzi wszystkich rozumiem, że:

za. moje pytanie jest do pewnego stopnia bezsensowne

b. nawet gdyby pytanie było całkowicie dokładne, odpowiedź brzmiałaby w zasadzie „nie, nie możesz cały czas używać tylko JQuery)

Shivan Dragon
źródło
25
Nieprawidłowe jest powiedzenie „używaj tylko JQuery” _ JQuery to biblioteka JavaScript.
superM
4
Bez pętli for lub while, bez zmiennych, bez funkcji? Wszystko to JavaScript.
superM
2
Przez „zwykły stary JavaScript” prawdopodobnie masz na myśli JavaScript DOM API. Możesz to sprawdzić i edytować pytanie, aby uniknąć zamieszania.
scrwtp
4
Czy kompatybilność między przeglądarkami nie jest wystarczającym powodem?
Simon Whitehead,
10
„Wygląda na to, że (jquery) jest w stanie używać go wyłącznie i nie trzeba dotykać JavaScript bezpośrednio”. To jest po prostu niepoprawne pod względem faktycznym. jQuery to po prostu zbiór funkcji JavaScript (aczkolwiek o dziwnych nazwach, takich jak „$”). Jedną z ważnych części zrozumienia jQuery jest ta realizacja. Jego dodatkowe funkcje obsługują manipulację DOM i zapętlanie.
Graham

Odpowiedzi:

113

Po pierwsze - nie można używać tylko jQuery, wszystko, co robi jQuery, to dodać obiekt $ do globalnego zakresu, z kilkoma metodami. Nawet bardziej manipulacyjne biblioteki, takie jak prototyp, nie są alternatywą dla javascript, są paskiem narzędzi do rozwiązywania typowych problemów.

Główne zalety dodania jQuery do paska narzędzi to:

  • kompatybilność z przeglądarkami - robienie czegoś takiego jak .attr () jest znacznie łatwiejsze niż natywne alternatywy i nie psuje się w różnych przeglądarkach.
  • uproszczenie zwykle skomplikowanych operacji - jeśli chcesz zobaczyć dobrze napisaną wersję metody XHR zgodną z różnymi przeglądarkami, zapoznaj się ze źródłem $ .ajax - dla tej metody jest prawie warta narzutu na jQ.
  • Wybór DOM - proste rzeczy, takie jak wiązanie zdarzeń i wybieranie elementów DOM mogą być skomplikowane i różnić się w zależności od przeglądarki. Bez dużej wiedzy można je łatwo napisać źle i spowolnić stronę.
  • Dostęp do przyszłych funkcji - rzeczy takie jak .indexOf i .bind to natywny język javascript, ale nie jest jeszcze obsługiwany przez wiele przeglądarek. Jednak korzystanie z wersji tych metod jQuery pozwoli na ich obsługę w różnych przeglądarkach.

JavaScript nie jest już tylko językiem po stronie klienta, a ponieważ jQuery jest tak zależny od DOM, jest to straszny kandydat do przeniesienia się na serwer. Bardzo polecam poświęcenie czasu na zrozumienie, dlaczego używasz jQuery (zadanie tego pytania to świetny pierwszy krok!) I ocenę, kiedy jest to konieczne. jQuery może być niebezpieczny, kilka głównych zagrożeń to:

  • jakość kodu - jQuery ma ogromną społeczność i niską krzywą uczenia się. To idealna burza dla wielu źle napisanych wtyczek typu open source.
  • nieefektywność - jQuery łatwo jest pisać nieefektywnie. Na przykład użycie jQuery's zamiast pętli jest niepotrzebne i może mieć wpływ na wydajność w niektórych przypadkach. Wiele dobrych informacji na ten temat w JSPerf
  • wzdęcia - jQuery to ogromna biblioteka. W większości przypadków użyjesz niewielkiego podzbioru jego funkcji i przejmiesz całą bibliotekę. Istnieje kilka świetnych alternatyw, które zapewnią ci podzbiory funkcji, takie jak zepto.js i underscore.js - w zależności od sytuacji możesz zaoszczędzić kilka bajtów, wybierając odpowiednią bibliotekę dla swoich potrzeb.

Ostatecznie jQuery to niezwykle przydatna i pomocna biblioteka, jeśli jest właściwie używana. Nie jest to jednak alternatywa dla javascript. Jest to biblioteka, podobnie jak zepto.js , YUI , Dojo , MooTools i Prototype - jedna z nich może być znacznie lepszym wyborem dla twojego obecnego projektu.

JavaScript jest niezrozumianym językiem i dopiero niedawno jest postrzegany przez większość ludzi jako coś więcej niż język skryptowy. Naprawdę polecam przeczytać więcej na ten temat, oto kilka dobrych miejsc na początek:

Edytuj 07/2014 - Zauważyłem, że ten post wciąż zyskuje na znaczeniu, więc dodałem kilka linków. Nie są one w określonej kolejności, ale powinny być pomocne.

  • Blog Bena Almana - wiele dobrych praktyk tutaj. Nie zgadzam się z nimi wszystkimi, ale cały czas uczę się nowych rzeczy z jego bloga.
  • Code Academy - podstawowe szkolenie z javascript i jQuery. Czasami pomaga powrót do podstaw.
  • JavaScript Garden - post dotyczący bardziej skomplikowanych lub źle zrozumianych funkcji javascript. Proszę przeczytać to od czasu do czasu, aż wszystko ma sens.
  • Bocoup - są to szkolenia. Jeśli jesteś blisko jednego, idź do niego. Naucza tego wielu najlepszych mówców i nauczycieli JS.
  • Blog Paula Irisha - nie tylko JS, ale napisano tutaj wiele dobrych praktyk. Kanały Twittera i Bena są świetne do naśladowania.
  • JavaScript: The Good Parts - książka Douglasa Crockforda, często nazywana „Biblią JavaScript”, jest niesamowitym miejscem do zrozumienia javascript.
  • Blog Isaaca Schluetera - Isaac jest twórcą npm i działa na rdzeniu węzła. Dużo pisze o społeczności javascript, a nie o konwencjach kodu, ale jeśli naprawdę docierasz do js, ​​jest to świetna lektura.
  • Douglas Crockford's Javascript - Jeśli Brendan Eich jest ojcem javascript, Douglas jest jawnym wujem javascript. Jest autorem specyfikacji JSON, Biblii javascript i wielu niesamowitych postów na temat dziwactw i błyskawicznego wzrostu javascript.
  • Blog Brendana Eicha - Brendan jest twórcą javascript - pisze na swoim blogu o wszelkiego rodzaju niemądrych rzeczach i chociaż ma swoje wady jako osoby, jego posty w javascript są cenne.
  • Blog Jamesa Hallidaya (@substack) - Substack jest prawdopodobnie najważniejszym deweloperem node.js w społeczności - z około 400 (i rośnie każdego dnia) modułów npm i wiodącą filozofią małych, podobnych do Uniksa modułów, wszystko, co pisze, jest warte czytanie.
  • Blog Maxa Ogdena Max Ogden jest kolejnym płodnym pisarzem node.js i doskonale pisze posty na blogu, które Cię czegoś uczą. Jest także autorem (wraz z innymi, jak sądzę) javascript dla kotów.
  • JavaScript dla kotów - to krótki samouczek, który zapozna Cię z podstawami języka JavaScript z perspektywy kota. Jeśli jesteś początkujący, przeczytaj to. Jest zabawny i w ciągu godziny uczy, jak wiele książek komunikuje się tygodniami.
  • Blog Nicholasa Zakasa Nicholas jest autorem kilku fantastycznych książek javascript: Object Oriented Programming in Javascript , Maintainable JavaScript , Professional Javascript for Web Developers oraz High Performance Javascript . Koncentruje się głównie na kliencie, ale ma mnóstwo najlepszych praktyk i wskazówek dotyczących wydajności.
  • Blog Guillermo Rauch - Guillermo jest kolejnym płodnym twórcą node.js, znanym głównie z Socket.io i Mongoose. Jego blog (i jego nowa książka Smashing Node.js są świetnymi zasobami.

Jestem pewien, że jest o wiele więcej wspaniałych zasobów, o których nie myślę i o których nie wiem, inni użytkownicy powinni odpowiedzieć na tę listę.

Jesse
źródło
3
+1 za uwagę dotyczącą JS nie jest już tylko językiem po stronie klienta i jak JQuery do tego pasuje.
Shivan Dragon,
1
Zauważ, że wszystkie funkcje są obiektami, ale jest cholernie blisko wszystkiego w JavaScript. $ jest lepiej opisany jako funkcja z przypiętymi do niego właściwościami „na poziomie klasy”, np. ( $.ajax), która wyrzuca obiekty opakowania zestawy elementów dom, które mają na celu uczynienie metod DOM ogólnie znacznie mniejszymi PITA poprzez uczynienie ich bardziej zwięzłymi, posiadającymi metody automatyczne zapętlanie zestawów obiektów dom, gdy ma to sens, i udostępnianie wspólnego, przewidywalnego interfejsu API między przeglądarkami (co stanowi mniejszy problem IE <= 8).
Erik Reppen,
1
To świetny post, ale chcę zakwestionować jeden punkt - „Ogromna biblioteka ... użyj Zepto / Underscore” - Po pierwsze, Underscore to zupełnie inny typ biblioteki - głównie do radzenia sobie z tablicami / obiektami - a także użyj LoDash zamiast tego jest szybszy. Po drugie, Zepto jest mniejsze PONIEWAŻ, ponieważ nie obejmuje tego, co robi jQuery. Może to prowadzić do błędów, które naprawiłoby jQuery. Wreszcie, jQuery NIE jest już tak ogromny / monolityczny, ma około 30 KB po zgzipowaniu, i możesz to zapisać, używając 1 mniej obrazu. Dla mnie uzyskana wydajność dewelopera jest warta tych bajtów.
LocalPCGuy
1
@LocalPCGuy zdecydowanie kilka dobrych punktów. Ten post został (dokładnie!) 2 lata temu i od tego czasu z pewnością zmieniło się w ekosystemie js. Na przykład osobiście używam przeglądarki i małych modułów zamiast jakiejkolwiek biblioteki o globalnej przestrzeni nazw. Myślę jednak, że podstawowa zasada jest nadal prawdą, a mianowicie, że w wielu (większości?) Przypadkach biblioteka zlewozmywaka kuchennego jest rzadko potrzebna. Złożyłbym to większości programistów, aby upewnić się, że właściwie uzasadniają koszt rozmiaru bibliotek, zanim zdecydują się go użyć, ponieważ jest to łatwiejsze niż sprecyzowanie, czego potrzebujesz.
Jesse
1
Reaguj na wszystkie rzeczy, mam rację!?!?! / sarkazm - co powiesz na wybranie odpowiedniego narzędzia do pracy @Andy i nie zawsze jest to React. Myślę, że React robi dobre rzeczy, ale nie udawajmy, że to lekarstwo na cały świat JavaScript.
LocalPCGuy
17

Są zalety, ale można dyskutować, czy naprawdę przewyższają wady.

Najważniejsze jest to, że oszczędzasz przepustowość i zyskujesz szybsze odpowiedzi. jQuery dodaje kolejne ~ 30kb do twojej odpowiedzi. W niektórych sieciach (i niektórych krajach) może to oznaczać kilka milisekund. Z drugiej strony możesz jednak łatwo ustawić buforowanie za pomocą swojego serwera internetowego (lub, jak powiedział Xion, użyj go ze strony Google, aby nie wpłynął na twój i nadal jest buforowany).

Drugą rzeczą jest to, że możesz potrzebować tylko bardzo prostych funkcji, a samo pobieranie i konfigurowanie jQuery może zająć więcej czasu niż zwykłe wdrożenie tego, czego potrzebujesz.

I na koniec, możesz chcieć stworzyć własną platformę, co jest w większości złym pomysłem, ale niektórzy ludzie mają swoje powody.

Jeśli jednak odrzucisz jQuery tylko dlatego, że jesteś zastraszany krzywą uczenia się, powinieneś ponownie rozważyć. Zwłaszcza, że ​​to raczej delikatne.

Yam Marcovic
źródło
Uzgodnione, szczególnie w zakresie przepustowości. JQuery 1.8.2 ma 92 KB w wersji zminimalizowanej / zaciemnionej. Zgodzono się również, że nie są to jednak bardzo mocne powody, aby nie używać JQuery. Dzięki!
Shivan Dragon,
1
@ShivanDragon: Zapomniałeś gzip. To czyni go znacznie mniejszym.
ThiefMaster
@ ThiefMaster: to prawda, dziękuję za zwrócenie na to uwagi.
Shivan Dragon,
10
Jeśli używasz jQuery z sieci CDN (takich jak Google one), istnieje prawdopodobieństwo, że użytkownicy wstępnie załadują go z innych stron. Stąd wpływ na średni (choć nie maksymalny) czas reakcji byłby mniejszy.
Xion
1
@Phil Dlaczego w ogóle go używasz?!?! jQuery nigdy nie był i nigdy nie będzie potrzebny. Jest to czysto satanistyczne zło (wraz z resztą gangu demonicznego: ReactJS, Underscore, LoDash, Modernizr, CommonJS, Angular, Google Analytics, zwłaszcza AMD itp.). Osobiście nigdy nie uwzględniłem całej biblioteki (chociaż rzadko wyodrębniam i optymalizuję określone funkcje, których potrzebuję z bibliotek), nigdy nie dołączę całej biblioteki i prawie każdej strony internetowej, którą tworzę, ładuje się przez Internet w mniej niż 11 ramkach (1/59 sekundy).
Jack Giffin
14

O ile mi wiadomo, tak naprawdę istnieją tylko dwie zalety używania javascript waniliowego w porównaniu do biblioteki takiej jak JQuery , MooTools itp.

  • Biblioteki mają ładunek, który pochłania przepustowość. Ale jak już wskazano w innych odpowiedziach, możesz to ograniczyć za pomocą gzipowania i buforowania. Jeśli chcesz tylko podzestawu jQuery, który możesz zrobić za pomocą SizzleJS, a dzięki MooTools masz możliwość wybrania zestawów funkcji, które chcesz w taki sam sposób, jak robi to Modernizr .
  • Biblioteki są duże i wymagają trochę czasu na naukę. Z drugiej strony jest to jednorazowa inwestycja dla programistów ... i dobrze wygląda na twoim CV, aby znać biblioteki javascript.
  • (BONUS) Biblioteki nie są srebrną kulą, więc jeśli chcesz wynaleźć koło na nowo, to zdecydowanie jest to dobra droga.

Warto wskazać, dlaczego chcesz korzystać z biblioteki javascript, dla której jest wiele:

  • Nie musisz pisać własnego frameworka, aby wspierać swój rozwój. Jeśli jesteś ciekawy, jak to działa, możesz sprawdzić kod, ponieważ jest to oprogramowanie typu open source.
  • Biblioteki rozwiązują problem zgodności przeglądarki. Zarówno DOM, jak i javascript mają pewne różnice między przeglądarkami. Zaufaj mi, to jest ogromne pochłanianie czasu, jeśli musisz samodzielnie zhakować poprawki.
  • Korzystanie z bibliotek javascript jest de facto standardem internetowym, większość z nich jest już dobrze udokumentowana, a większość programistów (znających javascript) umie z nich korzystać.
  • Naprawdę nie rezygnujesz z javascript podczas korzystania z biblioteki. Nadal musisz znać Javascript z jego typami, obiektami, działaniem zamknięć itp.
  • Większość bibliotek jest modularny i nie zajmuje dużo czasu na pisanie wtyczek lub wykorzystanie wymaga i wzór AMD .
  • Wybór elementów z DOM przez CSS jest ogromną pomocą.
  • (BONUS) Można ich używać również z CoffeeScript .

Pracowałem w sklepie internetowym, który był nieugięty w używaniu javascript waniliowy, ponieważ jQuery był duży i przerażający. Ta decyzja, na którą głównie wpłynął samotny „programista javascript”, była źródłem wielu błędów przeglądarki i powolnego rozwoju, a próba dostania się do jego bazy kodu była porywającym doświadczeniem. Pisanie własnego frameworka może wydawać się dobrym pomysłem, ale jeśli chcesz zatrudnić nowych programistów, nie mogą oni szybko wskoczyć i pomóc. Następnie należy rozważyć kwestię współczynnika magistrali .

Jak powiedziałem, pracowałem tam ... gdzie indziej były zielone pastwiska. : ^)

Łup
źródło
10

Zdarza się, że dość mocno mieszam użycie obu. Największym powodem tego jest to, że w niektórych aplikacjach (na przykład rozszerzenia chrome) nie potrzebujesz obsługi wielu przeglądarek. Co oznacza, że ​​mogę skorzystać z nowych osiągnięć, takich jak css3, które dzięki takim rzeczom, jak przejścia, mogą uprościć twój kod tonę niż użycie jquery.

Często też robię coś niestandardowego. Zupełnie jak inni mówili, że nie powinieneś wymyślać koła na nowo. Ale kiedy poprosiłeś o jakąś szaloną funkcjonalność, często łatwiej jest mi napisać ją samodzielnie, niż spróbować włamać się do wtyczki jquery, która jest blisko, ale nie idealnie.

Pracowałem również z programistami, którzy pracują wyłącznie z jquery. I muszę powiedzieć, że znacznie częściej kompromitowali funkcjonalność, jeśli nie mogliby znaleźć wtyczki jquery, która zrobiłaby to, co chcieli.

W pewnym momencie programowania zostaniesz poproszony o zrobienie czegoś, co nie jest spakowane w bibliotece. W tym momencie lepiej upewnij się, że rozumiesz, jak naprawdę działa język podstawowy.

Więc TLDC : Użyj obu, jesteś w niekorzystnej sytuacji, używając tylko wanilii i jesteś w niekorzystnej sytuacji, jeśli nie znasz wanilii wewnątrz i na zewnątrz i nalegasz, aby zawsze używać jquery.

Ryan
źródło
3
pure wanilia js to droga!
marko
Ryan niewiele wie, że jQuery potajemnie nadużywa document.querySelectorAllza kulisami.
Jack Giffin
6

Jedyną rzeczą, o której nie mogę się obejść bez JQuery, byłoby użycie wtyczek JQuery; nawet wtedy możesz napisać własną bibliotekę JS, która zapewni dokładnie to, czego potrzebuje wtyczka.

Pomyśl o tym w ten sposób: JQuery to biblioteka JavaScript typu open source napisana w języku Javascript; możesz spojrzeć na źródło, a tym samym nauczyć się robić wszystko, co robi.

Nie możesz używać JQuery bez zwykłego starego Javascript. Prawdopodobnie nie będziesz używać document.getElementById, ale nadal będziesz definiować funkcje i zmienne w standardowy sposób Javascript; możesz nawet napisać standardową forpętlę.

Główną zaletą korzystania z JQuery jest prawie taka sama jak każda inna biblioteka innej firmy w dowolnym języku: nie trzeba pisać tyle kodu, aby zaimplementować logikę specyficzną dla aplikacji.

Nie pozwól, aby rozmiar Cię odstraszył. Wersja CDN jest pobraniem ~ 33k, które zostanie zbuforowane przez przeglądarkę użytkownika po odwiedzeniu pierwszej strony.

Mike Partridge
źródło
6

Jeśli martwisz się wydajnością, powinieneś spróbować używać waniliowej js, gdy tylko jest to możliwe. Frameworki nie tylko zwiększają przepustowość, ale także przetwarzają. JQuery jest również kompatybilny z całkiem starymi przeglądarkami.

Jeśli pracujesz nad aplikacjami mobilnymi lub grami (lub obydwoma połączonymi), najpierw potrzebujesz wydajności i efektywnego zasobu.

jQuery i wtyczki mogą przyspieszyć twój rozwój, ale zwłaszcza jeśli polegasz na zewnętrznych wtyczkach jquery, powinieneś wiedzieć, co robią wewnątrz. Wiele z nich to złe przykłady jakości i wydajności kodu.

jQuery może być 2 do 10 razy wolniejszy niż natywny JavaScript. I może łatwo zachęcić programistów do niewłaściwego zaprojektowania interfejsu i zbyt dużego polegania na selektorach jQuery, które są znacznie wolniejsze niż natywne.

Jan Prieser
źródło
+1, zgadzam się z tobą, że tworzenie gier jest dobrym powodem, aby porzucić JQuery na rzecz waniliowego JS, ze względu na wydajność. Dotyczy to w większości języków, jeśli chodzi o tworzenie z nimi gry. Na przykład chłopaki Google zalecają w swoich dokumentach na Androida nie tylko porzucać biblioteki podczas tworzenia gier (w Javie, na Androida), ale także porzucać niektóre dobre praktyki kodowania na rzecz szybkości.
Shivan Dragon,
... jeśli wiesz tyle o efektywnej manipulacji DOM, jak ludzie piszący jQuery, tak.
Erik Reppen,
@ErikReppen prosimy o sprawdzenie prawdziwego kodu źródłowego od „osób, które piszą jQuery”. Byłem oślepiony przez prawie miesiąc od horrorów, które zobaczyłem w pierwszych 23 liniach.
Jack Giffin
Wiele zmieniło się w JQ od 2013 roku.
Erik Reppen