Od dłuższego czasu potykam się w sieci o wpisy, które próbują moralizować frontendowców tłumacząc im, że jQuery jest bee i nie powinno się go używać. Ale czy wszyscy zdają sobie sprawę jak ważna była ta biblioteka dla współczesnego frontu?
Nie jestem fanem jQuery, choć używałem go wielokrotnie. Jeszcze kilka miesięcy temu miałem kontakt z tą biblioteką, ponieważ jest niejako zaszyta we framework Marionette.js.
Gdy dawniej pisałem aplikacje na smartfony ze starszymi Androidami, starałem się używać jQuery jak w najmniejszym stopniu, bo wiedziałem, że wygoda „kosztuje”. Dlatego też w projekcie z marionetką bolało mnie używanie jQuery nawet przy prostych iteracjach. Szczególnie, że celowaliśmy w aplikację hybrydową i wydajność miała być jedną z kluczowych rzeczy. Oczywiście nie twierdzę w tym miejscu, że jQuery było głównym problemem, ale z pewnością odcisnęło swoje piętno.
Zastanówmy się jednak czemu go używaliśmy.
jQuery jest proste
Myślę, że nikt nie ma co do tego wątpliwości. O jQuery mówiło się kiedyś, że tworzy z nowicjuszy profesjonalistów. Oczywiście nie w aspekcie konstrukcji programistycznych, ale tego co można nim uczynić na stronach w błyskawiczny sposób.
Potrzeba nam pobrać wszystkie wiersze z tabeli i nadać im czerwone tło? Żaden problem!
Wystarczy napisać $('tr').css('background', 'red'); i gotowe! Przed pojawieniem się jQuery trzeba było poznać DOM API aby uzyskać to samo (co nie dla wszystkich było proste), natomiast ilość kodu była nieporównywalnie większa. Po premierze jQuery naturalnym wręcz było aby pobierać elementy strony za pomocą selektorów CSS. I kto wie, może miało to też pozytywny wpływ na poznanie CSSa? Magiczna funkcja $() upraszczała życie w różnych problemach i spowodowała, że skrypty na stronach posypały się jak oficjalna prezentacja windowsa 98. Tworzenie własnych skryptów stało się w banalnie proste i dostępne praktycznie dla każdego, nie tylko dla twórców stron. I co najlepsze: nawet nie trzeba było znać do tego JSa 😉 Znaczek dolara był jak czarna skrzynka do której wrzucało się różne rzeczy, a ona w odpowiedzi dawała niezwykłe rezultaty… No co? Kiedyś na prawdę robiło to wrażenie!
jQuery jest wygodne
Pamiętam po sobie ile razy dodawałem do projektu jQuery choćby po to by np. skorzystać z możliwości modułu $.ajax. Nie mogłem uwierzyć, że żeby wykonać zapytanie asynchroniczne w czystym JavaScripcie trzeba było wykorzystać tak brzydki obiekt jak XMLHttpRequest. A przecież w starszych IE to w ogóle była masakra, bo tam był jeszcze inny obiekt! Z jQuery mogłem zapomnieć o takich potworkach. Podobnie rzecz miała się z interfejsem użytkownika. Rozwijalna sekcja? Wystarczy użyć na pobranym elemencie funkcji slideToggle. Musimy wykorzystać na stronie suwaki i inne interaktywne elementy? Z pomocą przychodzi jQuery UI z biblioteką gotowych, jak to dziś byśmy nazwali, komponentów. Wygoda, a może lenistwo? Nieważne, to na prawdę działało!
jQuery ma wsparcie dla wielu przeglądarek
Przykłady użycia jQuery, które wymieniłem wcześniej nie miałyby sensu jeżeli musielibyśmy pisać ich różne wersje dla różnych przeglądarek. Na szczęście jQuery od początku swojego istnienia dbało o kompatybilność z wieloma przeglądarkami, udostępniając programiście odpowiednią warstwę abstrakcji. Dzięki czemu stereotypowy Jan „deweloper” Kowalski nie musiał się już przejmować bugami i różnicami w API między przeglądarkami. Obecnie szczęśliwa większość programistów nie musi już pisać na potworki typu IE6, a samo jQuery w swej najnowszej wersji również porzuciło wsparcie dla starszych przeglądarek. Ale jeszcze kilka lat temu taka abstrakcja nad wykonywaniem zapytań asynchronicznych, czy też nad dodawaniem obsługi zdarzeń do elementów, była po prostu nieoceniona.
jQuery jest rozszerzalne
Kolejny punkt, który z pewnością jeszcze bardziej przyczynił się do popularności tego skryptu. Biblioteka nie tylko posiada mnóstwo wszelakich pluginów (oficjalny rejestr pluginów można znaleźć tutaj), ale także umożliwia utworzenie własnego pluginu wręcz w banalny sposób. Wystarczy dopisać własną funkcję do obiektu $.fn i już możemy cieszyć się własną wtyczką, która np. dla wszystkich obrazów na stronie zastosuje filtr CSS ze skalą szarości:
$.fn.grayscale = function() {
this.css("filter", "grayscale(100%)");
};
$("img").grayscale();Prawda, że proste?
jQuery jest w pewnym sensie „standardem”
Przyznam szczerze, że nie znam osobiście frontendowca, który nie zna jQuery. Są frameworki, które posiadają znak $ jako swoją zależność, lub też pewien jego podzbiór nazywany „lite”. Stąd też znajdą się deweloperzy, którzy musieli się nauczyć przynajmniej podstaw tej biblioteki, aby móc pracować w wybranej technologii. Z drugiej strony barykady są zaś osoby doświadczone, dla których znajomość jQuery to „oczywista oczywistość”, a także ich przeciwieństwo – tzw. script kiddies, którzy nie mają pojęcia o podstawowych cechach JavaScriptu, ale jQuery znają, bo przydaje im się do „upiększania” swoich stron. Konkluzja jest taka, że ciężko jest znaleźć kogoś kto jQuery nie zna.
Bez jQuery prawdopodobnie nie byłoby wielu wygodnych rozwiązań
Kilka z tych rozwiązań przemyciłem już wcześniej, mam tu na myśli chociażby sam sposób pobierania elementów DOM za pomocą selektorów CSS. Obecnie mamy możliwość skorzystania z takich natywnych metod jak querySelector i querySelectorAll. Wspominałem także o wygodnym module $.ajax do wywołań asynchronicznych. Obecnie w nowych przeglądarkach możemy użyć metody fetch, która wydaje się jeszcze prostsza. Manipulacja klasami za pomocą takich metod jak np. addClass czy removeClass, jest od dłuższego czasu możliwa w postaci obiektu classList mającego metody add i remove. Nie trzeba także tęsknić za pętlą each, skoro dysponujemy natywnym forEach. Jeden z wzorców pisania zwany łańcuchowaniem (ang. chaining) został dość mocno spopularyzowany dzięki jQuery (i rzeczywiście ma tutaj sens). Można by jeszcze spróbować zaryzykować stwierdzenie, że także obietnice (ang. Promises) zostały spopularyzowane dzięki jQuery i jego $.Deferred, używane w wielu skryptach, także do animacji.
W wielu miejscach swojego API jQuery pokazało, że pewne rzeczy można spróbować zrobić prościej, aby programiście było po prostu wygodniej. Z pewnością odbiło się to na niejednej bibliotece i wielu nowoczesnych standardach, które są teraz masowo implementowane w przeglądarkach.
I ten ostatni punkt jest meritum mojego dzisiejszego wpisu. Nie chciałem w nim bronić jQuery jako biblioteki, która powinna być podstawą architektury dla współczesnych aplikacji. Chciałem pokazać, że dała nam na prawdę wiele do współczesnego frontu i nie podoba mi się hejt jaki niektórzy deweloperzy wylewają na tą bibliotekę. Jeżeli nie podoba Ci się ten całkiem pokażny zbiór użytecznych funkcji, to go po prostu nie używaj, nikt Cię do niego nie zmusza. Pamiętaj jednak, że to kawał dobrej roboty, który miał realny wpływ na to jak wygląda teraz sieć.
Któregoś dnia pożegnamy jQuery na dobre, szkoda by było wtedy słyszeć, że była to „katorga” dla deweloperów i że całe szczęście to już za nami. No cóż, może jestem po prostu zbyt sentymentalny.