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

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)

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

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.

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. : ^)

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.

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.

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.