To jest 9. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem będę rozmawiał o projektowaniu frontendu aplikacji webowych. Z tego odcinka dowiesz się:

 

* Co to jest frontend aplikacji webowych?

* Jakie technologie i języki programowania są używane do jego budowania?

* Opowiemy szerzej Java Script.

* Powiemy, czy front end musi być użyteczny.

* Jak się go testuje?

* Oraz jakie wyzwania stoją przez frontend developerem w codziennej pracy.

Zapowiada się jak zawsze ciekawie, więc nie przedłużając, zapraszam do rozmowy z moim gościem.

 

Witam Cię serdecznie w Porozmawiajmy o IT. Ja się nazywam Krzysztof Kempiński i w tym podcaście rozmawiam z moimi gośćmi o branży informatycznej, przedstawiam trendy, zjawiska i opinie. Staram się przybliżyć tę branżę tym, których w niej na co dzień nie ma, jak również zaciekawić stałych bywalców. Pozostań z nami.

A teraz zapraszam już na kolejny odcinek.

 

Krzysztof: Cześć! Witam! Dzisiaj moim i Waszym gościem jest Tomek Nieżurawski. Cześć Tomek! Bardzo mi miło, że zgodziłeś się wystąpić w podcaście. 

Tomek: Cześć!

Krzysztof: Tomek jest doświadczonym web developerem, specjalizującym się w technologiach front endowych. Pracował w kilku polskich i zagranicznych firmach, mierząc się z takimi technologiami jak przeróżne framework’i jak Java Script, CSS, także NodeJS i innymi technologiami backendowymi. Na co dzień pracuje zdalnie nad kilkoma aplikacjami frontendowymi dla berlińskiego startup’u i od niedawna jest dumnym tatą. A dzisiaj z Tomkiem porozmawiamy sobie o budowaniu, programowaniu, frontend aplikacji webowych. Tomek, dlaczego w dzisiejszych czasach nie mówi się już o budowaniu aplikacji webowych, tylko raczej rozdziela się to na frontend i backend? Czy mógłbyś krótko wyjaśnić, co to jest frontend i backend i dlaczego ten podział istnieje? I czy jeden programista nie może ogarnąć obydwóch tych rzeczy jednocześnie?

Tomek: Rzeczywiście jest tak jak mówisz. Odeszło się już od budowania takich monolitów, w których pomieszane mamy frontend z backendem i mimo, że jestem frontendowcem, to muszę przyznać, że najważniejszym powodem tutaj jest nie frontend, ale bac end, który jako taki serwer łączący się z bazą danych często operujący na jakichś operacjach, że tak powiem z dala od użytkownika, zaczął służyć wielu klientom i niestety frontend, czyli interfejs webowy jest tylko jednym z możliwych klientów. Innym może być jakaś aplikacja na IOS, Androida, możemy też zasilać danymi rozszerzenie do przeglądarki, smartwatch’e. Możemy też jakiś inny serwis zewnętrzny zasilać danymi. To nie musi być koniecznie jakiś interfejs graficzny, dlatego ten backend rzeczywiście musi być już oddzielnie. A innym powodem według mnie jest również też skomplikowanie tego frontendu. Na przestrzeni lat przeszliśmy z prostych stron na których jest tekst i może kilka zdjęć, do aplikacji, które np., to będzie chyba taki przykład znany wszystkim, pozwalają na edycję tekstu takiego jak Microsoft Word, który kilkaset Megabajtów zajmuje, więc często w bardzo prosty sposób jesteśmy w stanie wyklikać jakieś operacje, które pod maską skrywają skomplikowane procesy i na frontendzie jedną z głównych takich, może najlepszy komplement jaki można dostać, to tak korzystam z takiej aplikacji, taka prosta intuicyjna i tutaj sobie wyklikam itd. Także, żeby stworzyć taką prostą aplikację w obsłudze trzeba trochę dużo się napisać, trzeba też dużo rzeczy przewidzieć i myślę, że dzięki temu też ten frontend stał się tak skomplikowany i może powoli taki frontend developer stanie się pełnoprawnym inżynierem oprogramowania. Teraz przechodząc do twojego pytania czy jedna osoba, czy jeden programista nie mógłby robić tych obydwóch rzeczy naraz. Myślę, że jeden programista jest w stanie ogarnąć i frontend, i backend, ale tylko do pewnego poziomu. Taka ogólna zdolność do tworzenia prototypów, napisania tego wszystkiego samemu jest w ogóle świetną zaletą programisty według mnie, bo ma on taki przegląd pola. Wie z czym ta druga strona musi się mierzyć i to pomaga w komunikacji, ale specjalizacja to siła. Także nie ma szans, żeby taki fullstuck developer, czyli ten, co się zajmuje i frontendem i backendem, osiągnął taką biegłość w frontendzie czy backendzie jak programista, który cały swój czas poświęca tylko jednej z tych dziedzin. Myślę, że to nie dotyczy tylko programowania, ale też innych rzeczy. Także cóż, specjalizacja to siła.

Krzysztof: Dokładnie. Zgadzam się jak najbardziej. Teraz mamy już tyle różnych technologii, że jednej osobie bardzo trudno jest nadążyć za rozwojem wszystkich. Świetnie. To skoro wiemy czym jest frontend nie tylko aplikacji webowych, to powiedz proszę, jakie technologie są w arsenale takiego programisty jak ty? Z jakich klocków buduje się frontend?

Tomek: Myślę, że spora część słuchaczy pewnie już słyszała o takiej świętej trójcy jak HTML, CSS i Java Script. Są języki, w których, że tak powiem wszystko, jak twoja aplikacja wygląda, jak się zachowuje, piszesz w jednym języku, ale tutaj masz do dyspozycji trzy różne języki i według mnie jest to taka piekielnie słuszna koncepcja, aby rozdzielić to na trzy różne technologie, bo jedna jest dedykowana do opisu strony internetowej, która de facto jest dokumentem, opisujemy też jak ta strona ma wyglądać i jesteśmy w stanie definiować interakcje z użytkownikiem. To też pozwala, że te technologie, mimo że są połączone mogą trochę się rozwijać w różnym tempie i w różne strony. Także te trzy klocki dobrze, że są oddzielnie według mnie.

 Krzysztof: Wspomniałeś o tym, że frontend w twojej opinii powinien być traktowany równoprawnie jako taka inżynieria oprogramowania, ale w Internecie często widzimy takie memy, że HTML i CSS, to nie są takie pełnoprawne języki programowania jak inne. Według mnie nie do końca to jest prawda, gdyż wymagają one pewnej wiedzy i umiejętności, a Ty, co o tym myślisz?

Tomek: Po części tak rzeczywiście jest, że ten HTML można określić jako język znaczników, które pozwalają ci opisać dokument, tak jakbyśmy cofnęli się do jakiejś podstawówki i spojrzeli na swoją kartkę z wypracowaniem, jest nagłówek, jest stopka, jakiś obszar boczny, tutaj zwany marginesem, może na stronie to byłoby jakieś menu, jest wstęp, rozwinięcie, zakończenie, czyli teoretycznie nic się tam nie programuje, tylko opisujesz jak ta strona wygląda, jaka tam jest struktura. CSS natomiast to język, którym opisujesz, jak rzeczy mają wyglądać, ustanawiasz jakieś reguły, możesz np. ustanowić regułę wszystkie tytuły wyświetlamy na czerwono, więc tu też ciężko powiedzieć o jakimś programowaniu rzeczywiście. Bardziej też to jest takie opisowe, ale oba języki wymagają sporej wprawy i nie dziwię się tym wszystkim memom, jak najbardziej, w sumie nawet sam je lubię. Aby posługiwać się tym CSSem i HTMLem po prostu trzeba doświadczenia. Sprawy nie ułatwia fakt, że nasza aplikacja webowa może zostać uruchomiona dosłownie wszędzie i nie każda przeglądarka, czasami nawet system operacyjny, szczególnie jeśli chodzi o czcionki, interpretuje te reguły w ten sam sposób i niestety to powoduje pewne komplikacje. Jak kiedyś dostałem już zgłoszonego baga na tesli, na kokpicie tesli, na tym takim dużym tablecie, że coś tam źle się wyświetla i niestety nikt nie kupił tesli z zarządu, żeby to sprawdzić, więc can not produce i tyle. Także CSS jest fajną przygodą na pewno i HTML, ale jak widać wszędzie może zostać uruchomiony i to może sprawiać spore problemy.

Krzysztof: Ciekawy case z tą Teslą. Skupmy się na chwilę na Java Script. Wspomniałeś, że jest to jeden z tych elementów świętej trójcy frontendowej i widzimy, obserwujemy, że ten język ostatnio bardzo mocno ewoluuje. Kiedyś był tak traktowany jako troszeczkę kulawy język, któremu brakuje takich podstawowych konstrukcji. Od kilku lat dość powszechnie stosuje się AS6. Mógłbyś krótko, dlaczego ta wersja Java Script stanowi wielki krok do przodu?

Tomek: Na początek będę ubolewał nad faktem, że niestety JS dorobił się tej złej renomy i najgorsze dla mnie jako Java Script Developera też jest to, że ta zła renoma wynika z cechy tego języka, która jest taka w sumie najistotniejsza czyli jego plastyczność, można powiedzieć jakaś dynamika, dynamiczność, coś w tym stylu, to jest taki miecz obusieczny, powoduje, że w Internecie znajdziesz bardzo dużo złego kodu JS’owego i jak również możesz się zdziwić w jakich zastosowaniach użyto tego JS i w sumie to działa całkiem fajnie. Dużym usprawnieniem w as6, jak ma skrypt 6, są klasy, których brak odstraszał programistów języków klasycznych, ale rozwieję tutaj pewien mit, te klasy były dostępne w JS’ie już kilka lat temu, już spory kawałek lat temu i to, co widzimy dzisiaj jest po prostu takim lukrem syntaktycznym, ale wiadomo, że problem polegał na tym, że wsparcie takie klasowe musielibyśmy napisać sobie sami, więc jeśli każdy może napisać taką implementację, to mogą się one między sobą różnić i to jest fajna rzecz, jeśli chodzi o rozwój języka i eksperymentowanie, że możemy takie rzeczy robić, ale z drugiej strony oczekujemy też pewnych powtarzalności, i te klasy rzeczywiście są fajne i chętnie z nich korzystamy. Innymi rzeczami, które były możliwe, ale do zrobienia na okrętkę, albo to, co nimi osiągaliśmy było też tak do zrobienia, brzydko ten kod wyglądał, był taki trochę nieczytelny np. Arrow Functions, sporo nowych metod, jakieś domyślne wartości dla parametrów przekazywanych do funkcji itd., ale to też powiedzmy dałoby się zrobić. Co nowego rzeczywiście wnosi ten as6, to na pewno skok blokowy w JS’ie do tej pory był tylko skok funkcyjny, dla zmiennych takie rzeczy destrukturyzacja. Rzucę tylko hasłami.  Jest sporo tych rzeczy, które wniosła AS6, ale też tak naprawdę, co chciałem zaznaczyć, jest dużo rzeczy, które już były do tej pory dostępne, ale jednak okazało się, że fajnie by było mieć do tego interfejs jakiś nowy, jakieś tam słowa kluczowe i łatwiej po prostu tego używać.

Krzysztof: Świetnie. Myślę, że do notatek podlinkujemy jakiegoś tutorialu, który opisuje te wszystkie nowości, ale Java Script, to język, natomiast w realnych projektach wykorzystujemy framework’i i to, co obserwujemy, to fakt, że co raz więcej tych framework’ów powstaje, w dosyć szybkim tempie. Niektóre giną i nie są wspierane równie szybko, zatem jakie framerworki obecnie są najbardziej popularne?

Tomek: No tak, to jest kolejna faza skryptu. Ja mam zawsze takie porównanie, że społeczność jest bardzo prężna i buzują w niej hormony, że tak powiem wieku nastoletniego. Z przeświadczeniem, że możemy zrobić wszystko i jednocześnie nic nie musimy. Dlatego te projekty tak krótko żyją, To powoduje dużo zamieszania, ale też z drugiej strony dużo nowych idei jest testowanych i cały ten ekosystem się rozwija. Jest taka strona, która się nazywa dayssincelastjavascriptframework.com na której jest tylko liczba wyświetlona i tam ona oznacza, ile dni temu wyszedł ostatni nowy framework do Java Scripta i szczerze mówiąc, to zawsze jakaś niska liczba. Jakiś czas temu, chyba w zeszłym tygodniu sprawdzałem, to było, nie wiem, zero albo jeden. Także codziennie coś nowego wychodzi, ale oczywiście nie musimy znać tego wszystkiego. Najpopularniejsze framworki, to według mnie Angular. Ember, React i Miu, i też od razu powiem, wymieniłem je w kolejności alfabetycznej, żeby tu się nikomu nie narazić, bo to jest temat do frontendowych wojen.

Krzysztof: Zgadza się. Ten ekosystem się bardzo prężnie rozwija. Ja, jakiś czas temu, kiedy powiedzmy bawiłem się troszeczkę frontendem, to miałem do czynienia z takimi nazwę to technologiami jak Dżejkuery czy Bootstrap i pytanie do ciebie, czy to też są frameworki, czy to jest może jakieś pierwotne stadium rozwoju technologii, z którymi teraz mamy do czynienia? 

Tomek: Tutaj intuicja cię nie myli. Dżejkuery, to nie jest framework. Dżejkury, to biblioteka. Ona tak historycznie pomagała nam w zniwelowaniu różnic między przeglądarkami, upraszczała w dużej API do naszej strony, nad którą pracujemy. Mówię tutaj w czasie przeszłym, ale rzeczywiście jeszcze się tego używa i wiadomo, Internet nie skończył się po wejściu nowych framework’ów i może w przyszłości też będziemy wspierać aplikacje, gdzie tam mocno były wykorzystywane Dżejkuery, więc warto znać, ale dużo rzeczy idzie już zrobić takim normalnym językiem Java Scriptowym, nie trzeba korzystać z Dżejkuera i to myślę, że taki nowoczesny programista powinien być w stanie sobie poradzić bez Dżejkuery. A Bootstrapa rzeczywiście nazwałbym frameworkiem, ale frameworkiem CSS, bo znajduje się w nim wiele gotowych rozwiązań CSS-owych, dzięki czemu nasza strona wygląda tak po uruchomieniu całkiem ładnie, to sobie uruchomimy ją po prostu z tymi stylami, które są w przeglądarce, też przeglądarka pewne style ma, to wygląda, to źle ogólnie, dlatego Bootstrap pozwala na szybko się zorganizować i też dostarcza nam pewną taką strukturę , tzw. grilla, czyli jak szkielet naszej strony będzie wyglądał, także podstawowe wsparcie dla RWD i myślę, że to bardzo pomaga w tworzeniu i utrzymywaniu aplikacji od tej strony. I plus, jest popularny bardzo, więc programista wchodząc do takiego projektu widząc Bootstrapa, to jest w domu, bo już wielokrotnie z niego korzystał i to też jest dobre. 

Krzysztof: Myślę, że tak jak wspomniałeś te technologie jeszcze są dosyć żywe, pod tym względem, że jest mnóstwo mega C-kodu, które po prostu z nich korzysta. A powiedz proszę, czy w swojej pracy wykorzystujesz jakieś bardziej zaawansowane aspekty inżynierii oprogramowania związane z Java Script, typu design, patterns, czy tego typu elementy?

Tomek: Tak, generalnie tak. Chociaż wiadomo, znajomości i odpowiednie użycie wzorców projektowych jest zawsze w cenie, to jest zawsze na plus. Tutaj podzielę może się taką kontrowersją, moim takim własnym zdaniem, nie każdy może się z tym zgodzić, ale według mnie większość programistów, frontend’owców, dla nich używanie wzorców projektowych powinno być wymuszone przez framework, w którym pracują, bo myślę, że na każdego programistę takiego super ogarniacza, przypada wielu też, którzy po prostu chcą przyklepać kod. To nie mówię, że to jest coś złego, czy właśnie chce jakoś tutaj negować. Po prostu nie każdy aż tyle ogarnia albo nie jest jeszcze gotów, żeby tutaj zaproponować jakiś wzorzec, chociaż powinien oczywiście się tego nauczyć. Myślę, że tu rolą architektów jest takie napisanie systemu, żeby, że tak powiem te wzorce same się chciały używać, żeby aż było wiadomo, że tutaj jakiś tam wzorzec nam będzie pasował itd., więc to takie jest moje zdanie. Ale oczywiście też wiele podstaw z takich inżynierii oprogramowania, też takie hasła jak „Don’t repeat yourself”, „Keep it simple stupid” czy w pewnym sensie też Java Script „Solid”. Te rzeczy nadal obowiązują, to się nie zmienia. Inżynieria oprogramowania, to także takie korzystanie z odpowiednich narzędzi, które sprawią, że twój kod będzie lepszy. I to też taki must have dla programisty, frontendowca.

Krzysztof: Świetnie. Dobrze słyszeć, że takie praktyki są uniwersalne. Zgodnie z indeksem TOP, Java Script jest na 8 miejscu popularności języków i faktycznie ostatnio obserwujemy wysyp ofert o pracę do frontend developerów. Jak myślisz, z czego ta popularność wynika? 

Tomek: Przede wszystkim według mnie Java Script, to jest obecnie język internetu i pomimo wielu prób zdetronizowania tego JS’a, on jest nadal językiem, który jest obsługiwane przez przeglądarki. Możesz oczywiście w czymś innym napisać sobie tą stronę i często ona jest przekładana na Java Script, ale jednak ten Java Script równa się Internet tak naprawdę. Jeśli chcesz coś zrobić, to to mocno wpływa na popularność, ale też myślę, że jako że to jest język skryptowy, to on zawsze ma taki niższy taki próg wejścia. Dla początkujących programistów i w sumie chyba dla mnie, gdy zaczynałem, zobaczenie efektów swojej pracy po sekundzie czy dwóch, jest takim motywującym, świetnym feedbackiem, że chce się dalej coś zmieniać itd. Nie musisz mocno jakoś ustawiać tego swojego środowiska, bo nadal nie jest to preferowany sposób pracy, ale nadal wystarczy ci jakiś notatnik, napiszesz jakiś krótki kod i sobie zobaczysz efekt. Taki zawsze niski próg wejścia w coś myślę, że też sprzyja popularności.

Krzysztof: Wyjdźmy teraz troszkę poza Java Script, bo programowanie frontendu to nie tylko Java Script, chociaż stanowi jego bardzo mocną część. Wspomnieliśmy już o pewnych, podstawowych narzędziach dla frontendu, pewnych podstawowych technologiach. Jednak obecnie ten frontend, to dużo więcej, zaryzykowałbym. Chciałbym cię teraz zapytać o te inne aspekty. Zacznijmy może od Responsible Design. Co to jest i dlaczego praktycznie każda strona czy aplikacja powinna to wspierać w dzisiejszych czasach?   

Tomek: Resposible design, to w skrócie RWD powiedzmy, taki sposób tworzenia stron, aby wyświetlały dobrze niezależnie od urządzenia, na którym są uruchomione. Tak można w skrócie powiedzieć. Chociaż jeszcze trafniej można było powiedzieć, że niezależnie od rozdzielczości ekranów tychże urządzeń. Jak trzymasz przed sobą smartphona, to możesz mieć w dwóch rozdzielczościach, bo trzymasz go pionowo albo poziomo, to powiedzmy, że ta wysokość z szerokością się zamienia, więc na tą orientację też powinieneś zwrócić uwagę. Powiedzmy spektrum tych naszych urządzeń zaczyna się od smartphone’ów aż do, myślę, że monitrów 4K i to jest ogromna różnica na jakim obszarze nasza strona zostanie wyświetlona i niestety siłą rzeczy na mniejszych ekranach z czegoś będzie trzeba zrezygnować albo wyświetlić jakoś inaczej i pomaga w tym właśnie RWD, aczkolwiek zaryzykuje takie stwierdzenie, że w większości przypadków, w większości aplikacji musimy zadbać o smartphone’y, tablety i laptopy, jakoś tam niżej nie musimy schodzić i wyżej zbytnio też nie. Ale takim faktem, który mocno przemawia za RWD, jest to, że obecnie połowa ruchu generowana na Internecie pochodzi z urządzeń mobilnych, więc nasza strona musi się dobrze wyświetlać na komórce, jeśli chcemy dotrzeć do odbiorców. Myślę, że żaden biznes nie może sobie pozwolić na to, że nie będzie docierać od tak do połowy odbiorców, bo nie znamy się na RWD. Ale to wiemy, że jest to pewna generalizacja. Są też aplikacje, które mogą sobie pozwolić na coś takiego, nie wiem, jakiś system działający w intranecie, gdzie wiemy, że wszyscy pracownicy pracują na dekstopach, jakichś laptopach. My wiemy, że będą mieli duże monitory i nasza aplikacja może preferować tylko takie większe rozdzielczości i nie musimy pisać tego mobile’a. A RWD, takie testowanie, to jest zawsze pewien koszt, też inwestycja. Inwestycje mogą być trafione albo nie, tak to zdecydowanie jest jakiś koszt. Dla większości aplikacji bardzo opłacany.

Krzysztof: Dokładnie. Tego ruchu mobilnego nie możemy już ignorować w dzisiejszych czasach. Dbając o wydajność, o której pewnie jeszcze sobie opowiemy, często używa się narzędzi typu module bundler, takich jak webpack, gulp, buble, czy bower. Powiedz proszę, co to są za narzędzia i do czego służą?

Tomek: Zacznę tak, myślę, że chronologicznie, to trochę jest taka jakby historia Internetu w pigułce z co raz bardziej skomplikowanym aplikacjami webowymi. Nastała taka potrzeba, żeby lepiej organizować ten swój projekt i wiadomo, że korzystamy z zewnętrznych bibliotek i bower i MPM pozwoliły nam na łatwiejszy zaciąganie tych zewnętrznych bibliotek do naszych projektów, także to było duże usprawnienie. Grunt i gulp z kolei to uwolniły nas od wykonywania takich samych, żmudnych czynności podczas pracy. Na przykład, gdy wrzucamy kod na serwer, to powinniśmy go zminifikowwać, czyli zmniejszyć jego objętość przez usunięcie komentarzy, niepotrzebnych białych znaków, zamienienie zmiennych, np. dla komputera nie jest istotne, czy zmienna nazywa się users czy nazywa się A, a my możemy zaoszczędzić kilka znaków i to się wszystko złoży na mniejszą wagę strony. No i z gulpem i z gruntem możemy to zrobić tak, aby to się działo automatycznie. Nie jest to oczywiście jakiś nowoczesny wynalazek, bo możemy tu chociażby Mika wspomnieć. Bubble natomiast, to tzw. transfiler kodu. Wspomnieliśmy dzisiaj o AS6, jak również o trudności jaką nam przysparza uruchomienie strony na różnych przeglądarkach i te przeglądarki mogą być bardzo stare i język nasz as6 może być tam nie wspierany i Bubble konwertuje nasz kod napisany w as6 do wcześniejszej wersji, do as5. Jak widać tutaj przydaje się, to, że wiele rzeczy tam było właśnie takim lukrem syntaktycznym i rzeczywiście idzie to przełożyć na starszy język. My jako programiści możemy się cieszyć zdobyczami języki. Najfajniejszy kod pisać i wszyscy bardziej się rozumiemy z kolegami, o co chodzi, a jednocześnie dostarczać taki kod do starszych przeglądarek właśnie dzięki Bubble. Module bundler, o którym wspomniałeś, czyli webpack, to, zaryzykuję, wciąż swojego rodzaju nowym w świecie frontendowym, chociaż już wyszła wersja 4.4, to już dość wysoka, a webpack stara się osiągnąć takiego Świętego Graala frontendu. Teraz pytanie, co jest tym Świętym Graalem? I to jest ogólnie dostarczanie użytkownikowi tylko tej części aplikacji, jaką on potrzebuje, żeby wykonać daną czynność. Chcemy, żeby te nasze aplikacje były super wydajne, żeby nasi użytkownicy nie odczuwali dyskomfortu, żeby nie czekali, gdy przechodzą z punktu A do B. I głównie mamy dwie strategie, albo załadujemy wszystko na raz, całą stronę, i wtedy jak użytkownik będzie przechodził między stronami, to już będzie mu się z pamięci wszystko ładować, czyli będzie szybko pomiędzy stronami, ale poczeka tak długo na ładowanie strony tej początkowej, że wielu użytkowników sobie odejdzie. Możemy też przeładowywać każdą stronę, oczywiście ładujemy mniej, że tak powiem, tak już było. To też się raczej nie sprawdziło, bo ładujemy dużo razy to samo. I taki module bundler próbuje wyjść z tej sytuacji jakoś tak powiedzmy dobrą ręką, chcemy podzielić naszą aplikację na mniejsze części i ograniczyć te straty. Także możemy zrobić coś takiego, że nasze settingsy, ustawienia, w które użytkownicy rzadko wchodzą podejrzewam są innym bundlem i on tam będzie doczytywany dopiero jak oni wejdą w te ustawienia i to ogólnie zaoszczędzi nam dużo łącza, ale też sprawi, że aplikacja dużo szybciej się ładuje, a smaczku dodaje fakt, że zbyt dużo modułów spowoduje ogólne odczucie spowolnienia aplikacji ze względu na opóźnienia z natury sieci, jeżeli wszystko co kliknę, dotknę itd. będzie musiało poczekać aż zaciągniemy jakiś JS, który to obsługuje, to też będzie źle. Także ten webpack i tutaj temat bundlowania, to myślę, że nadal będzie na pograniczach sztuki inżynierii jak to wszystko wyważyć.

Krzysztof: Super. Dzięki, że to wyjaśniłeś. Teraz chciałbym porozmawiać o takim aspekcie frontendu, jakim jest bycie blisko użytkownika końcowego. Czy w związku z tym, że ten frontend jest blisko usera, taka osoba jak ty, programista, który na co dzień pracuje, musi być jakoś wyczulona na user experience, na kolory i aspekty wizualne? Czy takich umiejętności można się nauczyć, czy po prostu trzeba się z nimi urodzić?

Tomek: To jest dobre pytanie. Według mnie frontendowiec nie musi umieć projektować grafiki, ale musi wiedzieć, czy coś dobrze wygląda albo czy się tego dobrze używa. Powiedziałbym trochę, że jak krytyk filmowy, ale krytyków nikt nie lubi, a wolałbym, żeby frontendowcy ludzie jednak lubili, więc nie wiem, może jaki kulinarny krytyk, coś w tym stylu. Możesz po prostu nie umieć przygotować tej potrawy, ale wiesz, czy ona jest dobra czy nie. Oczywiście dobrze by było, jeśli byłbyś w stanie jako frontendowiec wytłumaczyć designerom swoje wątpliwości, może zaproponować jakieś rozwiązanie. Oczywiście nie jestem pewien czy tego da się nauczyć, ale kiedyś pracowałem z genialnym grafikiem, który był nawet wielokrotnie nagradzany za design internetowy, kiedyś właśnie w kuchni ktoś mu powiedział: „Łukasz, jesteś świetnym artystą. Świetne te grafiki robisz.” A on zarzekał się, że nie jest artystą, jest tylko rzemieślnikiem, także, wierzę, że tego rzemiosła idzie się nauczyć i może idzie coś z tego ogarnąć.

Krzysztof: Ja z kolei kiedyś pracowałem z typowym artystą, który mówił, że nie jest rzemieślnikiem, ale doświadczenia podobne. Frontend developer powiedzmy musi przełożyć ten desgin, który dostaje właśnie od takiego grafika na te trzy podstawowe technologie jakimi są HTML. CSS i Java Script. Jakich narzędzi oprócz Photoshopa się do tego używa i na ile frontend developer musi mieć tego Photoshopa opanowanego? 

Tomek: Myślę, że znajomość Photoshopa się trochę przydaje, aczkolwiek też już trochę mniej, bo kiedyś cięło się ten design na mniejsze grafiki w Photoshopie. Nie byliśmy w stanie np. zaokrąglić rogów w naszych boksach, nie byliśmy w stanie rzucić cienia, zrobić gradientów itd., a obecnie dobrze zorganizowany zespół deignerów korzysta z takich narzędzi takich jak: In Vision albo Zeplin i frontendowiec podgląda sobie te elementy, gdzie już ten CSS jest wygenerowany. Nie tworzy się jakaś strona, z której kupiłem sobie kod, ale możemy sobie podejrzeć jak ten element jest zrobiony i np. zobaczyć jak ten cień został rzucony. A w dzisiejszych czasach, gdy CSS już to wszystko potrafi, to głównie o to chodzi, żeby poznać tego CSS’a, który za tym efektem stoi, więc myślę, że już znajomość Photoshopa co raz mniej, ale zawsze się trochę przyda.

Krzysztof: Jasne. Ok, czyli mamy design, zostaje on przełożony na działającą aplikację frontendową i przechodzimy do testów. Na szczęście co raz powszechniejsza jest świadomość tego, że testowanie jest potrzebne. Powiedz proszę, jak się testuje aplikacje frontendowe? 

Tomek: Typów testów jest wiele i pewnie, i w ogóle mam nadzieję, że poruszysz ten temat w jednym ze swoich odcinków, bo ja ogólnie bardzo lubię testowanie, więc z chęcią posłucham. Generalnie rzecz ujmując na frontendzie posługujemy się testami jednostkowymi oraz testami funkcjonalnymi. Te testy jednostkowe, to może będzie też trochę dziwne, co powiem, pozwalają nam lepiej poczuć się z własnym kodem lub z cudzym kodem, ponieważ tak naprawdę testujemy pojedyncze funkcje, w taki sposób jakby nic innego dookoła nie istniało, jest tylko wejście i wyjście. Coś podajemy, coś wychodzi. Jak wyszło nie to, co się spodziewaliśmy, to źle. To bardzo ułatwia nam refakturyzację kodu, a ta w dobrym projekcie dzieje się dość często. Także dzięki tym testom, dbamy o jakość naszego projektu, to jest istotna sprawa. A testy funkcjonalne, to takie scenariusze, które klikają wewnątrz naszej aplikacji jak taki niesamowicie szybki user, bot klika skrypt i dzięki niemu możemy sprawdzić, czy nasza aplikacja rzeczywiście wykonuje i w pewnym sensie wyświetla to, co powinna. Ogólnie żadne testy nie gwarantują, że nasza aplikacja jest bez bagów, to wiadomo, ale testy jednostkowe, jakieś pokrycie 100%, wcale nie gwarantuje, ze nasza aplikacja działa, ponieważ każdą funkcję testujemy osobno i może się okazać, że dziś brakuje np. połączenia i użytkownik w ogóle nie mógł się zalogować do swojej aplikacji, a na testach jednostkowych wszystko jest ok. Jeśli chodzi o testy funkcjonalne, to już nam powie, że coś tutaj jest nie tak, nie można się zalogować w tym scenariuszu i też tak powiedziałem, że można sprawdzić, czy się wyświetla to, co powinno, to też nie tak do końca, bo skrypt może udaje, że jest człowiekiem, to nie jest tak do końca tym człowiekiem i on szuka elementów na stronie, może się okazać, że przycisk, który on klika, to w ogóle jest jakiś koślawy, brzydko wygląda, ale idzie go kliknąć, także funkcjonalność działa, ale dla na frontendzie to jest bardzo źle, jeśli coś tak brzydko wygląda, bo np. przycisk mógł wyjść poza ekran i w ogóle go nie widać, ale bot go widzie w dokumencie i jest w stanie go kliknąć, a użytkownik go nie widzi i to też jest pewien problem. Dlatego jest trzecia kategoria, o której w sumie nie chciałem wspominać, ale wspomnę, to są testy regresywne CSS, bo to jest rzadko spotykana technika, ale na podstawie algorytmów porównywania obrazów jesteśmy w stanie wychwycić, czy jakaś tam drobna zmiana, nie zepsuła czegoś w ustawieniach. A to się dzieje dzięki temu, że np. jak robimy testy funkcjonalne przed wypełnieniem formularza, tego loginu, robimy sobie screen shota, wpisujemy złe dane, naciskamy zaloguj i pokazują się errory i robimy kolejnego screen shota. Dla testu funkcjonalnego najpewniej wszystko będzie ok, a dla testu regresywnego możemy wychwycić, że w sumie te errory, to się źle wyświetlają, bo tutaj marginesy w ogóle się rozjechały czy coś w tym stylu i to jest też takie myślę, że marzenie wielu frontendowców dostać czas na zaimplantowanie takich testów i to chyba wszystkie testy, które są istotne na frontendzie.

Krzysztof: Tak, testowanie, to jest bardzo szeroki temat i trudno zawrzeć to wszystko w odpowiedzi na jedno pytanie. Myślę, że nagram na pewno odcinek o testowaniu, ponieważ dostaję informacje, że to może być temat ciekawy dla słuchaczy. A chciałbym teraz nawiązać do wydajności o której wspomniałem we wcześniejszym pytaniu. Z racji na to, że aplikacja webowa działa w przeglądarce, po stronie użytkownika, istotne stają się właśnie takie kwestie jak czas wykonania czy wydajność, i jakie możliwości optymalizacji w tej kwestii mamy?

Tomek: Myślę, że po pierwsze wybieramy dobre narzędzie do powierzonego nam zadania, także framework’i są bardzo podobne w pewnym sensie, ale też od siebie różnią, ale czasem to ich w ogóle tak naprawdę nie potrzebujemy, a to już istotnie wpływa na wydajność naszej strony, a samo zagadnienie wydajności, to też niestety temat na oddzielny odcinek, dlatego rzucę tylko kilka takich podstawowych zagadnień, kluczy. Niektóre są oczywiste i może mógłbym o nich nie wspominać, ale jak się okazuje jednak nie są takie oczywiste, czyli np. optymalizujemy wszystkie nasze obrazki. Chodzi oczywiście, by jak najmniej zajmowały, ale też chodzi o wybór dobrego formatu, bo to mocno też determinuje, czy coś będzie mniej miejsca zajmowało, aby się ładnie wyświetlić, Oczywiście jak wspomniałem wcześniej, minifikujemy nasz HTML, CSS, Java Script, włączamy kompresje danych statycznych na serwerze i też ogólnie opóźniamy ładowanie rzeczy, które nie są niezbędne na start i tutaj się kłania ten Module Bundler, ładujemy obrazki te, których nie widać dopiero jak user gdzieś tam do nich się do scrolluje. No niestety użytkownicy nie scrollują do końca strony najczęściej. To można sobie w jakiś analyticsach zobaczyć, więc nie warto ładować tych wszystkich obrazków na raz, to też spowolni stronę. Też jest taka technika, która się nazywa CSS above the fold, czyli jakby ponad tym zagięciem ekranu, czyli tylko to, co jest na starcie ekranu widoczne, tylko tego CSS’a pchamy do przeglądarki, a po chwili zostanie doładowana reszta i tutaj CSS jest tekstem, nie jest, aż taki ciężki, ale głównie chodzi o to, że on jest interpretowany, trzeba by renderować, trzeba zająć się właśnie przeliczaniem różnych styli, to trochę czasu przeglądarce zajmuje, więc to też możemy zoptymalizować, Są jeszcze takie sztuczki typu wydajność postrzegana, czyli persift performance. My jesteśmy w stanie przedstawić dane w taki sposób, ten proces ładowania danych, że użytkownikowi się wydaje, że strona ładuje szybciej, to też tylko rzucam hasło do wygooglania, to są fajne rzeczy i można się zdziwić, że rzeczywiście na stronach jest to używane. A jeśli chodzi o samo pisanie wydajnego kodu, to wydaje mi się, że zależy od zastosowania. Uważam osobiście, że takie mikrooptymalizacje są szkodliwe, że np. napiszemy super szybki kod, ale taki nieczytelne dla kogo innego w tym naszym projekcie, a rzecz tutaj, zysk rozegra się o milisekundy. Użytkownik nie zobaczy tego, tych milisekund zysku i nie będzie w ogóle tego świadomy, a to nam utrudni w przyszłości pracę nad kodem. I tu też oczywiście jest jakaś generalizacja, bo są zastosowania, gdzie milisekundy się złożą, zsumują i będzie nieszczęście. Ale tak, jestem zwolennikiem robienia takich optymalizacji najpóźniej jak się da.

Krzysztof: Dzisiaj rozmawiamy sobie o programowaniu frontenda aplikacji webowych. Czy ty w swojej pracy musisz rozumieć, jak działa backend? Chociażby po to, do takiego stopnia, by uruchomić backend na swojej maszynie, móc całość testować lokalnie? Czy takie zrozumienie pomaga tobie i w dalszej perspektywie projektowi poprzez ułatwienie komunikacji z backendowcami?

Tomek: Szczerze mówiąc w większości projektów, w których pracowałem, to wiedziałem mniej więcej, co się dzieje na tym backendzie. Żadnych szczegółów, nic bym tam nie edytował. Nic bym nie wykomitował. Ale jakieś rozumienie tych samych koncepcji jest ważne i też tak dzisiaj rozmawialiśmy o tym fullstuck developerze, myślę, że popracowanie nad jakimś projektem, powiedzmy, że po godzinach, gdzie tworzysz wszystko i będziesz miał do czynienia w gruncie rzeczy z tym backendem bardzo później pomaga w komunikacji z backendowcami, bo wiesz z jakimi problemami będą się mierzyć, więc to takie większe zrozumienie dla pracy innej osoby, to jest zawsze na plus. A jeśli chodzi o testowanie lokalne, to szczerze mówiąc nie wyobrażam sobie inaczej, aby frontendowiec nie umiał postawić backendowego projektu i vice versa, backendowiec też powinien postawić frontendowy projekt, dzięki czemu będzie mógł to wszystko sobie łatwo, fajnie testować, z rzeczywistym systemem, powiedzmy rzeczywistym w developmencie. I też taką moją praktyką, którą mogę się podzielić, to jest, że ja często piszę taki FAQ do backendu, zadaję różne pytania backendowcom i gdy rozwiązaliśmy jakiś problem, to sobie opisuję, co zrobiliśmy, bo on za trzy miesiące znowu może się pojawić i ja nie będę pamiętał jak naprawić to, a też nie chcę kolegom gitary zawracać za bardzo, więc sprawdzam sobie w moich notatkach, o faktycznie miałem taki problem powiedzmy trzy miesiące temu i rozwiązuje go sam, to nie oznacza, że ja się tam znam na tym backendzie i całym tym środowisku, tylko mam już jakiś zestaw notatek. 

Krzysztof: Bardzo fajna praktyka uważam. A jakie jeszcze inne wyzwania oprócz zrozumienia backendu stoją przed frontendowcami? 

Tomek: Myślę, że poprawne zrozumienie tego, co ma zostać zaimplementowane oraz, to chyba dla wszystkich, komunikacja z innymi członkami zespołu tak, żeby każdy wiedział, co robić i myślę, że nad tym warto pracować codziennie. A takim wyzwaniem dla frontendowca, jest nadążanie za zmianami w tymi świecie frontendowym. Język i cały ekosystem rozwijają się szybciej niż jesteśmy w stanie to ogarnąć i niestety, aby programować na wysokim poziomie trzeba dużo pracować. Myślę, że czasem więcej niż te wysiedzenie ośmiu godzin w pracy. I pomocna tutaj na pewno może się okazać specjalizacja, np. chcesz na froncie zajmować się tylko grafiką 3D. Możesz, to jest bardzo szeroka specjalizacja, trudna i można się w tym specjalizować, dostanie się oczywiście fajne oferty pracy, ale oczywiście jest to wąska rzecz i przychodząc do jakiejś innej pracy też niby na frontendzie albo też z Java Script’em, ktoś może ci powiedzieć: „Kurczę, ty w sumie tego JS’a to ty w ogóle nie znasz na serwerze, tego Java Scriptu, a niby jesteś Java Script developer. I to też są takie niebezpieczeństwa związane ze specjalizacją i to jest najtrudniejsza rzecz dla frontendowca. Też w codziennej pracy, dlaczego w codziennej pracy? Bo też czasami musisz na jakiegoś konia postawić, jeśli chodzi o te framework’i i czemuś się poświęcić, z czymś pracować, a może się okazać, że twój framework z którego korzystasz, przestaje być już tak popularny, zostanie ubity i musisz się czegoś nowego uczyć. I takie to są wyzwania frontendowe.

Krzysztof: Tak wspomniałeś o różnych technologiach, o różnych specjalizacjach. Mam wrażenie, że kiedyś ten próg wejścia w zawód front nd developera był znacznie niższy. Czy według ciebie łatwo jest zostać frontend developerem i czy to jest zawód z perspektywami na dzień dzisiejszy? 

Tomek: Zdecydowanie kiedyś było łatwiej i też powiem, że ja mogę mieć nieobiektywne zdanie na ten temat, bo ja zaczynałem swoją przygodę ze stronami Internetowymi jakoś na przełomie 2001/2002 roku, więc mogłem zostać potraktowany jako ktoś, kto już zapomniał jak to jest się uczyć czegoś, jak zrobić pierwszy krok, że ten pierwszy krok zawsze jest najtrudniejszy, więc ta moja odpowiedź będzie trochę nieobiektywna, ale według mnie łatwo zostać frontend developerem, ale ciężko jest właśnie ze względu na to, że wszystko tak szybko się zmienia. Bardzo ciężko jest być bardzo dobrym front end developerem, jeśli nie jest to twoja pasja, ale dla osób, które mają wyczucie estetyki jakiejś, a jednocześnie nie są uzdolnione graficznie, ja sam zupełnie nie potrafię rysować, lecz powiedzmy, że mają takie inżynieryjne podejście do rzeczy, bo lubią sobie po prostu po hakować, po programować, a jednocześnie nie chcą spędzić gdzieś tam życia na serwerze, w piwnicy, to jest to myślę, że ten frontend development, to jest taki fajny zawód i sprawiający wiele satysfakcji, szczególnie, gdy użytkownicy raportują, cieszą się, ze interfejs jest intuicyjny, jakoś bezproblemowo korzystają z owoców twojej pracy. To też jest, taka notatka na marginesie, to też jest w drugą stronę działa, że jak błędy są zgłaszane dla frontendu, to często jest tak, że połowa tych błędów to tak rzeczywiście coś na backendzie, albo z bazą danych się zepsuło, ale wszyscy, a tutaj kliknąłem coś nie działa. To na pewno frontend zepsuł, więc to też wtedy jesteś oczywiście na tym froncie, czyli jako pierwszy, którego praca jest doceniana, ale też często jakoś tam hejcona. Co do perspektyw, to uważam, że jest to zawód perspektywiczny. Ja bym go wybrał ponownie, chociaż w dzisiejszych czasach kusiłoby mnie również, pozycja programisty, który zajmuje się sztuczną inteligencją czy Machine Learningiem, uczeniem maszynowym, też wydaje mi się ciekawym tematem, ale frontend też jest ciekawy.

Krzysztof: Bardzo fajna odpowiedź. Dzięki. Wiele razy już tutaj dzisiaj wspomnieliśmy, że aplikacje webowe stają co raz bardziej wyszukane, zaawansowane i Java Script wkracza w co raz to nowe zastosowania, łącznie z backendem, z aplikacjami mobilnymi. Jaka przyszłość czeka frontend developerów i jakie trendy rozwoju widzisz dla najbliższej przyszłości?

Tomek: To jest zawsze trudne pytanie o przyszłości jakie, będą trendy. Nie będę tutaj mówił w takim sensie, że 2018 czy 2019 to jest rok Reacta, albo rok Angulara, czy coś w tym stylu. Te wojny to będą sobie trwały itd., ale możemy się skupić na czymś, co jest rzeczywiście może, że tak powiem, być game changerem. Jest taki gorący temat, który może zmienić sposób, w który postrzegamy aplikacje mobilne, to jest taki zbiór technik, który się nazywa progressive web apps, w skrócie cała strona jest aplikacją mobilną, ale tym razem nie mówimy o budowaniu aplikacji mobilnych przez react native czy jakieś mniej wysublimowane metody, tylko nową pełną klasę aplikacji. Zobaczymy, czy firmy będą tego używać. Java Script, HTML i CSS z powodzeniem, też są stosowane do aplikacji desktopowych przez taki projekt, który nazywa się Elektro, i również do aplikacji mobilnych, gdzie mamy react native, też bardzo fajny, fajnie się w tym pisze i dla frontend developera stworzenie aplikacji mobilnej, która rzeczywiście zachowuje się jak aplikacja mobilna, bo się koniec końców używa natywnych elementów, jest czymś naprawdę fajnym, fajnym doświadczeniem, ale pytanie jak bardzo nasycone są to rynki, by otwarcie się na takie nowe sposoby tworzenia aplikacji przez frontend developerów miały na coś większego wpływ.  O tym dopiero się przekonamy. JS można też uruchomić na hardwarze, ja tu polecam sprawdzić projekt Jerry Script, to jest taki obszar Internet of things, także można sobie coś w domu podziałać z jakimś inteligentnym domem czy coś. Też w sumie ciekawy temat. I ważnym w sumie i bardzo ciekawym tematem są mikrointerakcje, niestety często na froncie nie mamy na to czasu, aby zrobić jakieś takie ładne animacje, które właśnie są zwane mikrointerakcjami, po naciśnięciu jakiegoś przycisku zmiany stanu czy coś w tym stylu, ale biblioteki takie jak Top Motion mogą pomóc frontendowcą i być może więcej tutaj będzie do działania dla ludzi, którzy taką animacją elementów będą chcieli się zajmować. Ogólnie myślę, że cały ekosystem będzie się dynamicznie rozwijał, więc to jest w sumie dobra opcja, by się JS’em czy ogólnie frontendem zainteresować, no i to chyba tyle. 

Krzysztof: Super. Tomku, ja ci bardzo dziękuję. Super, że podzieliłeś się swoją szeroką wiedzą i doświadczeniem ze słuchaczami podcastu. Myślę, że zainteresowałeś niezdecydowanych do spróbowania i zmierzenia się z programowaniem frontendu. Powiedz proszę, gdzie cię można znaleźć w Internecie i jak się z tobą skontaktować?

Tomek: Po pierwsze dziękuję za zaproszenie. Trzymam kciuki za podcast. Jest kilka miejsc, gdzie można mnie znaleźć, ale przyznam szczerze, że jestem z tych developerów, którzy programując, nie znaleźli czasu na promowanie się w sieci czy coś w tym stylu, więc najlepiej do mnie napisać na tomasz@niezurawski.pl. Można też odwiedzić mojego bloga na Medium, gdzie mój nick to tommaqs. Ja wciąż wierzę, że znajdę więcej czasu, by podzielić się czymś fajnym, zarówno jakimiś podstawami, też takimi bardziej zaawansowanymi tematami.

Krzysztof: Świetnie. Bardzo ci dziękuję. Do usłyszenia. Hej!

Tomek: Dzięki. Do usłyszenia. 

Krzysztof: I to wszystko z tego, co przygotowałem dla Was na dzisiaj. Bardzo fajna i ciekawa rozmowa z Tomkiem, który mam nadzieję przybliżył wam realia frontendu nowoczesnych aplikacji webowych i realia pracy nad nim. Wszystkie linki znajdą się w notatce tego odcinka, a notatkę tę możecie znaleźć pod adresem porozmawiajmyoit.pl/9. Bardzo dziękuję wam za wysłuchanie. Ten podcast tworzę za darmo, więc w zamian proszę o recenzję na iTunes i Spriker, co pozwoli mi kontynuować pracę i docierać do szerszej grupy odbiorców. Dodatkowo zapraszam do kontaktu ze mną, piszcie na adres krzysztof@porozmawiajmyoit.pl. Tymczasem miłego dnia, wieczoru czy nocy, zależy, kiedy tego słuchacie i zapraszam do kolejnych odcinków podcastu. Hej!

Dziękuję Ci serdecznie za wysłuchanie kolejnego odcinka podcastu Porozmawiajmy o IT. Chciałbym, by ten podcast docierał do jak najszerszego grona słuchaczy. Możesz mi w tym pomóc, zostawiając gwiazdki i opinię w katalogu iTunes lub innej aplikacji, z której korzystasz do słuchania podcastów. Będę Ci wdzięczny za podzielenie się informacją o tym podcaście w mediach społecznościowych. Jeszcze raz dzięki za bycie ze mną i do usłyszenia w kolejnym odcinku. Cześć.