Transcription

Co tańczy deweloper naprawiający błędy? Mówię, mówię. Cześć, tu Roman, witam w kolejnym odcinku mojego vloga. Dzisiaj przygotowałem odcinek, który wpierdolił Kijów Mrowisko po raz kolejny. Uwielbiam to robić i uwielbiam tworzyć te wszystkie niekończące się gównoburze w komentarzach wynikające z mojego tematu, który właśnie w tym odcinku zamierzam na przykład poruszyć. Ale były też inne kontrowersyjne tematy na tym vlogu. Niemniej, ten jest kolejnym z nich. Jest może jakoś zajebiście kontrowersyjny, ale nadal budzi dość spore emocje i radykalne opinie. Zanim jednak cokolwiek powiem w tym odcinku, to chcę podkreślić, że to co tutaj mówię jest moją i tylko i wyłącznie moją opinią. Nie jestem jakimś, kurwa, nie wiem, wszystko wiedzącym. Jestem po prostu gościem, który ma własne zdanie i dokonuje własnych obserwacji rzeczywistości. I oczywiście można się ze mną nie zgadzać. Co więcej, jeśli macie argumenty, które przeczą moje opinii, to jak najbardziej wklejajcie je w komentarzach. Ja bardzo lubię z Wami dyskutować. Bardzo lubię poznawać Waszą perspektywę, Wasze opinie, bo na tym to wszystko polega. I nie chodzi tutaj o to, żeby się wszyscy ze wszystkimi zgadzali, bo wtedy świat byłby super nudny. Więc zaczynamy. A zacznę od tego, że co tydzień na Instagramie w sobotę robię taką ankietę, w której pytam ludzi, czego nauczyli się w zeszłym tygodniu. I to jest taka nasza tradycja na Instagramie. W ogóle, jeśli nie obserwujecie mojego Instagrama, to ja Was tam serdecznie zapraszam, bo ja tam często pokazuję jakieś fragmenty odcinków, które kręcę. Albo jakieś eksperymenty z kodem, które robię. Generalnie dużo się tam dzieje i jeśli jeszcze nie macie mnie na Insta, a macie Insta, to ja Was tam serdecznie zapraszam. Adres widzicie teraz na ekranie. No ale wracając do tej ankiety. Ludzie tam często piszą, że uczą się back-endu, front-endu, jakichś technologii konkretnych, Reacta. Wszystkiego się tam uczą i bardzo często pojawia się jednak zdanie, że ktoś uczył się jQuery. I tak, to jest ten odcinek, w którym powiem, dlaczego nie warto uczyć się jQuery w 2019 roku. Wzwyż. Jakby w 2020 też nie trzeba będzie się tego uczyć. Tak myślę. Bardzo często, gdy odpowiadałem właśnie na te ankiety, gdzie ktoś powiedział, że uczył się jQuery, gdzie mówiłem, że nie ma to sensu, to bardzo często właśnie pojawiała się kolejna fala pytań, która brzmiała, dlaczego, Roman? Więc chcę mieć taki odcinek, do którego mogę odesłać, w razie czego, żeby po prostu zawrzeć tutaj wszystkie argumenty. Wiadomo, że nie można tego zamknąć w jednym zdaniu, trzeba się trochę wygadać, więc po to ten odcinek. Ale najpierw krótka lekcja historii. Dlaczego w ogóle powstało jQuery? jQuery powstało w 2006 roku. To jest ten sam rok, kiedy Światło Dzienne używała przeglądarka Internet Explorer 7. Część z Was pewnie totalnie tego nie pamięta, bo była na przykład super mała. Wiem, że oglądają mnie osoby, które na przykład mają teraz po 15-16 lat, więc zakładam, że po prostu no to nie były Wasze czasy na korzystanie z komputerów, a przynajmniej nie na takie świadome korzystanie. Niemniej fakt, że Internet Explorer 7 wyszedł w tym samym czasie mniej więcej co jQuery, jest tutaj znamienny, bo chciałem tutaj powiedzieć, że wszystkie przeglądarki w tamtych czasach nie były doskonałe. To znaczy nawet dzisiaj nie są, ale to jakie API one wtedy oferowały, to jakie ogromne różnice pomiędzy nimi istniały, to wszystko było tak przytłaczające i tak problematyczne, że faktycznie fajnie jakby się pojawiło jakieś narzędzie, które trochę ułatwia pracę deweloperom, zwłaszcza właśnie na frontendzie, w pracy z domem i tak dalej. W tamtych czasach API służące do przemieszczania się po domie, do wyszukiwania jakichś elementów domu i tak dalej nie było aż tak dobre, nie było tak przyjazne dla deweloperów, dlatego jQuery starało się właśnie sprostać temu zadaniu i po prostu w bardzo łatwy sposób pozwalało na łapanie elementów do zmiennych, następnie mogliśmy je w jakiś sposób tam modyfikować, mogliśmy pobierać ich właściwości, takie jak na przykład szerokość, mogliśmy się generalnie wiele dowiedzieć właśnie za pomocą jQuery, które dzięki swojemu API umożliwiało nam dość łatwą manipulację tym domem. I generalnie w ciągu kilku lat od powstania jQuery tak to wszystko dobrze się przyjęło, że po prostu deweloperzy to pokochali. jQuery miało bardzo łagodną krzywą uczenia się, było naprawdę bardzo proste do nauczenia się, API było naprawdę dobrze udokumentowane, fajnie się z tego korzystało i co najważniejsze jQuery łatało te różnice między przeglądarkami, które sprawiały, że na przykład na jednej przeglądarce coś nam działało, na Internet Explorerze nie działało nic, a my musieliśmy się tym wszystkim martwić i łatać ten kod samodzielnie, generalnie to nie był najlepszy pomysł. I właśnie to sprawiło, że jQuery tak dobrze zostało przyjęte przez środowisko deweloperów, bo po prostu leczyło ich problemy w kodzie. Tak więc stabilność działania i ten doskonały developer experience, ta przyjemność spisania łatwego, wysokopoziomowego kodu sprawiła, że jQuery stała się po prostu najpopularniejszą biblioteką Javascriptu i do dziś gości na milionach stron internetowych. Ja się wcale temu nie dziwię. No dobra, i skoro historię już mamy za sobą i znamy jakby przyczyny, dlaczego w ogóle ta biblioteka powstała i dlaczego zyskała tak ogromną popularność, to teraz trzeba się cofnąć, a właściwie wrócić do 2019 roku i odpowiedzieć, jak to wygląda dziś. Przede wszystkim twórcy przeglądarek zaczęli współpracować nad unifikacją standardów, które obowiązują w przeglądarkach. To znaczy, że te różnice, które mamy w przeglądarkach nadal istnieją, ale nie są tak dotkliwe jak kiedyś. Zazwyczaj teraz jeśli mówimy o Firefoxie czy Chromie, to mówimy tutaj o takich różnicach, że jakaś przeglądarka już wspiera jakieś eksperymentalne featury, na przykład w Javascriptie czy w CSSie, a inna jeszcze tego nie wdrożyła. To generalnie są takie różnice i zazwyczaj jak coś nam działa w Chromie, to zazwyczaj będzie działać też w Firefoxie. Z Safari może być różnie. Z Edgem już na pewno nie jest takie źle jak z Internet Explorerem. Generalnie wszystko zmierza ku temu, żeby to wszystko stało się trochę bardziej przyjazne dla dewelopera. Oczywiście nadal możemy posiłkować się takimi rzeczami jak Polyfile czy Babel w momencie, kiedy wiemy, że będziemy musieli wspierać jakąś przeglądarkę, która po prostu jeszcze nie wspiera tych feature'ów, które chcemy wykorzystać. Wtedy Babel zajmuje się właśnie łataniem tego wszystkiego i upewnianiem się, że nasz kod będzie działał też na starszych przeglądarkach. Ale fakt jest taki, że przez te... trzy w pamięci... trzynaście lat? Trzynaście lat development na froncie zmienił się nie do poznania i stał się na pewno dużo przyjemniejszy. Więc to, co mówiłem o jQuery kiedyś, że właśnie dawało tę stabilność i pozwalało na działanie na wszystkich przeglądarkach, bo było po prostu tak dobrze połatane, tym już się nie musimy przejmować, no bo mamy inne narzędzia, które dbają o to, żeby nasz JavaScript działał właśnie na wszystkich przeglądarkach, ten czysty JavaScript, a niekoniecznie jQuery. Ale to, co jest chyba najważniejsze, to od 2015 roku, czyli od wejścia w życie ECMAScript 6, teraz już mamy wersję dziesiątą w tym roku, po prostu JavaScript się niesamowicie rozwinął. Featury, które mamy teraz, obecnie, zarówno w samym czystym JavaScript'cie, jak i w WebAPI, jak i w wszystkich metodach do właśnie przemieszczania się po domie i tak dalej, to wszystko się tak cudownie zmieniło, że korzystanie z jQuery w obecnym momencie moim zdaniem nie ma kompletnie sensu, bo JavaScript stał się bardzo czytelnym, przyjemnym językiem. Więc teraz taka szybka runda, co oferowało nam jQuery i jak możemy to zastąpić w JavaScript'cie. Oczywiście nie uwzględnię tutaj wszystkich tych różnic, nie opowiem tutaj o wszystkich substytutach, które posiadało jQuery, ale chcę opowiedzieć o takich kilku istotnych, które ludzie, nie wiem, pamiętają z rozżywieniem i po prostu lubią to, ale może nie wiedzą, że mogą to zrobić w czystym JavaScript'cie, albo może po prostu nie chcą. Ja uważam, że te wersje JavaScript'owe są po prostu teraz już lepsze. Runda pierwsza. Takim najbardziej rozpoznawalnym feature'em jQuery było chyba łapanie elementów za pomocą tego dolara. I oczywiście tego dolara w czystym JavaScript'cie nie mamy, ale mamy Query Selector, który moim zdaniem działa naprawdę bardzo dobrze i po prostu łapanie elementów za pomocą Query Selectora jest banalnie proste. Banalnie proste to jest tak zwany pleonazm, którego nie powinienem używać, ale jakoś tak weszło mi w krew. Postaram się go nie używać następnym razem. Tak czy inaczej dolar nie jest nam potrzebny w JavaScript'cie, a nawet jeśli chcemy tego dolara, to wcale nie potrzebujemy jQuery, ponieważ ta metoda, która łapie nam elementy za pomocą dolara została przeniesiona do osobnej biblioteki, do której link znajdziecie w opisie, jeśli jesteście ciekawi po prostu, jak możecie to sobie wykorzystać, jeśli tęsknicie za dolarem. Kolejną rzeczą w jQuery, która bardzo dobrze została przyjęta i która była namiętnie wykorzystywana przez wszystkich deweloperów to były animacje, to były te wszystkie Hide, Show, Fade In, Fade Out i tak dalej. Generalnie to, jak dobrze teraz działa CSS, pozwala nam na korzystanie po prostu z CSS-a i z manipulowania klasami za pomocą JavaScript'u. Nie potrzebujemy animować rzeczy w JavaScript'cie, a zwłaszcza tak prostych jak Fade In czy Fade Out. Jeśli chcemy jakieś takie super skomplikowane animacje, to z kolei moim zdaniem jQuery ssało power w tym momencie i dużo lepiej było wykorzystać taką bibliotekę jak na przykład GSAP, która też jest dość stara, ale na pewno jest dużo lepsza jeśli chodzi o animacje pod względem wydajności, ale też pod względem API. A jeśli już jesteśmy przy manipulacji klasami, no to jQuery też oferowało bardzo fajne API, które pozwalało nam na dodowanie, odejmowanie klas i tak dalej. Natomiast w JavaScript'cie też to się pojawiło w międzyczasie i mamy teraz przecież ClassList, który ma swoje metody add, remove, toggle, pickContains, z tego co pamiętam. To API ClassList jest naprawdę świetne, dobrze się z tego korzysta. Nie widzę powodów, dla których mielibyśmy korzystać z jQuery tylko po to, żeby manipulować klasami w JavaScript'cie. jQuery też pozwalało nam na pobieranie szerokości, wysokości elementów za pomocą metody with, height i tak dalej. Natomiast w JavaScript'cie pojawiło się coś takiego jak getBoundingBox... getBoundingClientRect. Dłuższej nazwy nie mogli wymyślić i tu się zgadzam, że nie jest to najprzyjemniejsza nazwa do wymawiania i do zapamiętania nigdy jej nie pamiętam, zawsze mi się coś popieprzy w tej nazwie. Natomiast można sobie z niej za pomocą destrukturyzacji wyciągać właśnie with, height, położenie na osi X czy Y. Jest to super wygodne, bo możemy tak naprawdę z jednej linijki wyciągnąć sobie wszystkie te zmienne, wszystkie te wartości, które potrzebujemy. I to jest oczywiście kropla w morzu tego, co obecnie potrafi JavaScript i co jakby po drodze zyskał, a co kiedyś oferowało jQuery i co teraz już nie jest tam do końca potrzebne. Więc mam nadzieję, że Was przekonałem i na koniec chciałem tylko powiedzieć, kiedy warto uczyć się jQuery, bo to nie jest tak, że jestem jakimś radykałem i po prostu wyrzuciłbym tę bibliotekę do kosza, to wcale nie jest tak. Moim zdaniem warto uczyć się jQuery wtedy, kiedy naprawdę musicie, czyli kiedy jesteście przyparci do muru i dostaliście na ryj jakiś projekt z Legacy Code właśnie w jQuery napisany, który po prostu musicie utrzymywać, musicie tam dowozić nowe featury, chociaż moim zdaniem bardzo fajnie byłoby, gdybyście zaproponowali też stopniowy refaktor, czyli po prostu dodając nowe featury, przy okazji krok po kroczku jakieś małe elementy refaktorować na czysty JavaScript, a może jeszcze wykorzystywać jakieś inne technologie, ale generalnie, żeby to trochę współcześnić. I to też oczywiście nie jest zasada. jQuery nadal jest rozwijane i na pewno jeszcze długo, długo sobie nigdzie nie pójdzie, więc jeśli nie widzicie absolutnie żadnego sensu w refaktorze, to też nie mówię, żeby to robić za każdym razem, ale ja bym do tego tak podszedł i na pewno bym zweryfikował, czy nie da się tego zrobić, czy nie daje to mi jakiejś korzyści. Natomiast jeśli chodzi o pozostałe przypadki, czyli takie, gdzie macie tę możliwość podjęcia decyzji, czy chcecie korzystać z jQuery, czy nie chcecie, nawet jeśli to jest mała strona, to naprawdę zachęcam do korzystania z czystego JavaScriptu, bo korzystanie z niego teraz jest naprawdę super przyjemne, ten kod jest czytelniejszy i też nie będziecie tak związani jakąś biblioteką, jeśli to jest jakiś mały projekt, bo do dużych projektów wiadomo, że już używa się trochę innych rzeczy. Tak czy inaczej, tak jak mówiłem na początku tego odcinka, jQuery ma bardzo łagodną, krzywą uczenia się. Czy to w ogóle jest po polsku? Czy ktoś zna jakąś poprawną wersję tego wyrażania? Ale chyba tak to się mówi. W każdym razie, bardzo łatwo się go nauczyć, więc nawet jeśli będziecie potrzebowali gdzieś wykorzystać jQuery, to myślę, że tydzień z dokumentacją to jest max, żebyście opanowali to w bardzo dobrym stopniu i to tyle. Dajcie znać, co wy o tym myślicie, jakie macie podejście do starszych technologii, zwłaszcza do jQuery. Czy nadal uważacie, że jest potrzebne? Czy zgadzacie się ze mną, czy może totalnie nie? Pokójcie mi się w komentarzach, zachęcam do tego, byle byłoby to kulturalne. Pamiętajcie, że ja bardzo lubię dyskutować, ale jak to mówiła moja mama, lubię gnój, ale w kubkach. Więc porządek musi być. Wielkie dzięki za obejrzenie tego odcinka, na razie. Jeszcze jednej ważnej rzeczy wam nie powiedziałem. Na koniec października jadę na ReactiveConf do Pragi i razem z twórcami tej konferencji przygotowałem dla was niespodziankę, o której opowiem wam za tydzień. Więc jeśli ktoś się nie wybiera, albo jeszcze nie wie, że się wybiera, to może się wybierze. Za tydzień szczegóły.