Czego nie wiesz o front-endzie

Czego nie wiesz o front-endzie

Półtora roku temu, kiedy zdecydowałem, że czas skupić się w pełni na front-endzie, zauważyłem wśród moich znajomych programistów dziwne poruszenie. Front-end? Kolorowe przyciski i zabawa w grafika? Przecież dopiero co zostałeś programistą, a teraz przeskakujesz na front-end?

Tak – tej gałęzi programowania można zarzucić wiele. Niektórzy sprowadzą ją do kwiatków w JSie żeby pokazać, że na front-endzie nie ma miejsca na aplikacje z prawdziwego zdarzenia. Inni, z powodu układu warstw aplikacji będą ignorować jej wpływ na wartość biznesową produktu, a ktoś do tego wszystkiego doda, że front-end to już właściwie pogranicze grafiki komputerowej więc co to za programowanie. Ile w tym wszystkim prawdy? Moim zdaniem niewiele, ale po kolei…

Nie umiem w grafikę – nie mogę pracować na front-endzie

Zacznijmy od rozprawienia się z podstawowym mitem na temat tego zawodu. W środowisku utarło się dość popularne przekonanie o front-endowcu którego najważniejszą umiejętnością jest tworzenie “ładnych” projektów. No tak – skoro mówią, że mam tworzyć “ładne” rzeczy, a nie potrafię rysować oraz nie ukończyłem ASP, to nie nadaję się do tego zawodu. To nie dla mnie.

Zastanów się – czy miałeś kiedyś tak, że w trakcie korzystania z jakiegoś serwisu zaczął cię irytować trudny w obsłudze interfejs? Kiedy na stronie banku szukałeś godzinami możliwości wykonania najzwyklejszego przelewu? Kiedy okno nie chciało się zamknąć pomimo klikania w ten właściwy przycisk? Kiedy na skutek złego wyboru opcji utraciłeś wszystkie postępy prac? Czy naprawdę chodziło wtedy o to, czy coś jest ładne?

Nie, głównym problemem który podświadomie zauważyłeś była użyteczność – a właściwie jej brak.

Użyteczność jest często mylona z warstwą wizualną, a to prowadzi do błędnego przekonania co do wymaganych umiejętności front-end developera. Tak, dobrze byłoby, gdyby osoba zajmująca się front-endem była wrażliwa na trudne w obsłudze interfejsy użytkownika, ponieważ będzie pracować w warstwie aplikacji, w której odbywa się interakcja użytkownika z produktem. Nie oznacza to jednak, że brak umiejętności obsługi Photoshopa skreśla twoje szanse na powodzenie. Wręcz przeciwnie – mocniejsze skupienie się na użyteczności tego co robisz pozwala dostarczyć coś z czego będzie można skorzystać bez przewracania kolejnych stron z instrukcji obsługi.

Brak jednej definicji

Można iść dalej. Jeśli nie chodzi o robienie ładnych rzeczy, to o co tak naprawdę chodzi na front-endzie? Czy front-end to strony internetowe realizowane dla znajomego? Czy HTML bez JS to front-end? Czy CSS jest najważniejszy? Czy front-end to przyciski i animacje? W zasadzie… wszystko to jest tak samo prawdziwe i od wszystkiego znajdziemy specjalistów. Z każdym dniem przekonuję się, że to, co kiedyś wydawało mi się specjalizacją w bardzo ogólnym zawodzie programisty, teraz w żaden sposób pasuje do tego co myślałem. Tak, front-end dotyczy pewnego ściśle określonego “miejsca” w każdej aplikacji, jednak to miejsce można badać na tysiąc sposób. Jak to więc wygląda od strony technologicznej? Na pewno większość was zna te trzy podstawowe klocki z których złożymy świat front-endu…

Zacznijmy od tego wspomnianego już kilka razy wyglądu tego co robimy. Jeśli wygląd, to style – prawdopodobnie CSS. Jeśli CSS, to CSS który się skaluje, który nie jest jednym wielkim plikiem style.css, tylko czymś składającym się z modułów, czymś co łatwo komponować. W dzisiejszych czasach praca ze stylami to rzadko goły CSS – wolimy posługiwać się LESSami, SASSami, czy PostCSSami, a ostatnio czymś co nazywa się CSS-in-JS. Od CSS zatrudniamy ekspertów i robimy konferencje poświęcone tylko temu tematowi.

Nasze style są bezużyteczne, jeśli nie mamy ich na co nałożyć. W klasycznym podejściu nasze CSSy połączymy zapewne z HTMLem. Dla wielu praca z HTMLem to ten biedniejszy brat prawdziwego programowania. Czy to znaczy, że HTML to losowy zbiór znaczników których używamy w dowolny sposób? Dla kogoś, kto nigdy nie zaglądał do specyfikacji, pewnie tak. Okazuje się jednak, że nie taki losowy ten HTML, jak mogłoby się wydawać. Dobry HTML nie jest tak głośny i modny jak nowe frameworki w JSie, a jednak to fundament każdej strony internetowej od którego również znajdziemy specjalistów i konsultantów.

No i w końcu to, co dla niektórych jest synonimem słowa front-end. Mowa oczywiście o języku JavaScript. Możliwości, jakie JS daje nam w połączeniu z CSSem i HTMLem są dla każdego front-endowca i webdeva nieocenione. Tutaj jesteśmy już chyba najbliżej “klasycznego” programowania. JS to oczywiście setki konferencji, frameworki o których huczy cały internet, języki kompilowane do JavaScriptu, wzorce projektowe, dobre i złe praktyki. Tak, JS to coś, w czym można się specjalizować.

To wszystko o czym napisałem ma ogromną wartość, ale tak naprawdę to tylko część ogromnego świata front-endu. Jeśli znamy połączenie CSS + HTML + JS, to czy musimy pamiętać o czymś jeszcze?

Warstwa interakcji – o co należy dbać

Jak to w życiu bywa – teoria teorią, ale z prawdziwymi wyzwaniami na front-endzie przyjdzie nam się zmierzyć dopiero w praktyce.

Wyobraź sobie, że jesteś członkiem start-upu startującego do przetargu za którym stoi organizacja rządowa. Czytasz wszystkie najpopularniejsze agregatory treści dlatego wiesz, w czym w 2017 “robi się apki”. Używasz najmodniejszej technologii, najlepszych narzędzi, twój produkt ma najlepsze ficzury, a koniec końców zapominasz o możliwości zmiany rozmiaru czcionki na stronie. Projekt który realizujesz jest odrzucony z powodu braku spełniania standardów dostępności. Accessibility, o którym mowa, nie jest najgorętszym tematem w świecie front-endu, ale to wciąż nasza odpowiedzialność. Front-end dba o to, żeby twoją stronę mógł skonsumować czytnik treści, żeby sama treść była dostępna dla osób z ograniczeniami, albo żeby elementy były rozmieszczone tak, żeby nawigacja bez myszki była naturalna.

Kolejną rzeczą, o którą często na front-endzie walczymy, jest wydajność i konsumpcja zasobów. W grach komputerowych wszyscy przyzwyczajeni są do ekranu “Loading”. Czy chciałbyś jednak, żeby po wejściu na PoznajProgramowanie.pl zobaczyć najpierw pasek ładowania, następnie napisy “Ładowanie zasobów…”, a po minucie zobaczyć stronę główną? Nie! Chcesz wpisać adres naszej strony w przeglądarce, nacisnąć ENTER, i sekundę później czytać nowego posta. Aby strony internetowe działały w ten sposób, ich warstwa front-endowa musi być odpowiednio zoptymalizowana. Mówię tutaj chociażby o rozmiarze obrazków, kolejności ładowania skryptów, operacjach na DOMie, czy dołączaniu tylko niezbędnych modułów w przypadku bardziej rozbudowanych aplikacji. Niestety – to często tylko teoria…

Czymś, co często związane jest z front-endem, ale niekoniecznie z front-endowymi frameworkami, jest analityka. Front-end jest zazwyczaj tym miejscem, w którym dołączamy skrypty z narzędzi analizujących, jak z naszej strony korzystają użytkownicy, w co klikają i ile czasu spędzają na stronie. Programista zajmujący się front-endem musi być świadomy tego, co dzieje się z kodem strony po dołączeniu skryptu o którym twórca mówi, że “wystarczy wkleić i działa”. Jak wpłynie na wydajność, czy ingeruje w zawartość strony, czy próbuje pobierać dodatkowe zasoby? Jeśli będziemy się posługiwać sprawdzonymi narzędziami to nagle okaże się, że w obszarze zainteresowań front-endowca może znajdować się badanie zachowań użytkowników, testowanie adopcji danej funkcjonalności czy niekończące się prace nad optymalizacją interfejsu użytkownika. To z perspektywy użytkownika ma o wiele większe znaczenie, niż framework którego używamy “pod maską”.

To tylko trzy przykłady tego, że na nauce JS’a, CSS oraz HTML świat się nie kończy. Poza tematami które wymieniłem na każdego front-enda czekają rozmaite potyczki związane z samą przeglądarką, internetem czy publikowaniem treści. Mam tutaj na myśli chociażby tematy takie SEO, UI/UX, ale też optymalizacja treści pod kątem mobile, responsywny design czy wszystko to, co wiąże się z komunikacją pomiędzy klientem i serwerem.

Front-end a design

Tej kwestii poświęcam osobny podpunkt, ponieważ “bliskość” front-endu i szeroko rozumianego designu była tym, co jakiś czas temu przekonało mnie do pójścia drogą na której aktualnie jestem.

Zanim zająłem się programowaniem, przez dość długi czas interesowała mnie głównie grafika komputerowa, o czym pisałem w jednym z poprzednich postów. Właśnie dlatego nie po drodze było mi z technologiami które pokazywały swoją moc na back-endzie. Szukałem miejsca, w którym mógłbym połączyć swoje umiejętności związane z “robieniem ładnych rzeczy” z pasją do programowania. Miejscem, które było do tego idealne okazał się front-end.

Na początku napisałem, że front-end to nie tylko wygląd. Nie da się jednak zaprzeczyć, że lepszego połączenia pomiędzy programowaniem oraz zapewnianiem dobrego wyglądu danej funkcjonalności nie znajdziemy poza front-endem. Front-end to miejsce, w którym spotyka się design z programowaniem. Jak to zwykle bywa w przypadku takich połączeń, czasami nie obejdzie się bez konfliktów, długich dyskusji i iteracji w dochodzeniu do czegoś co jest “gotowe”. Grafik odpowiedzialny za wygląd przygotuje layout którego nie da się zaimplementować – konflikt. Programista nie ma ochoty implementować możliwych do wykonania, ale skomplikowanych layoutów – konflikt. Layout nie spełnia estetycznych preferencji programisty ( 😉 ) – konflikt. Tak, w tej kwestii na front-endzie bywa gorąco.

Praca designera bez implementacji jest bezużyteczna. Tak samo jak najlepiej zaprojektowane pod kątem kodu komponenty, bez odpowiedniego wyglądu są bezużyteczne. Nie da się jednak zaprzeczyć, że połączenie tych dwóch światów przynosi niesamowite efekty. Tak doskonale nam znane “design systemy” jak chociażby Material Design nie mogłyby powstać, gdyby osoby odpowiedzialne za wizję i implementację nie usiadły w jednym pokoju, nie ustaliły celów i ograniczeń i nie zaczęły za sobą współpracować. To oznacza mniej więcej tyle, że ty jako front-end developer stoisz w takim samym miejscu i masz potencjał do realizowania takich samych projektów.

Bliskość designu i front-endu jest o tyle interesująca, że często pozwala zabijać nudę i rozwijać się w różnych kierunkach jako programista. W danym momencie masz ochotę rozwinąć się pod kątem architektury – bierzesz na tapetę komponenty i szukasz tego najlepszego projektu twojej aplikacji. Chcesz jednak rozwinąć twoją wrażliwość estetyczną? Wszystko co musisz zrobić to znaleźć projekt związany np. z tym wspominanym design systemem i od następnego dnia twoim głównym zainteresowaniem jest wygląd aplikacji, przygotowanie bazy komponentów w określonym stylu, oraz możliwość wysokopoziomowego komponowania UI. To wszystko w tym samym front-endzie, w którym podobno chodzi o to, czy Angular czy React.

Developers productivity

Czy na front-endzie znajdzie się miejsce dla programistów niekoniecznie zainteresowanych tym, o czym pisałem powyżej? Co jeśli nie masz ochoty koordynować rozwoju warstwy wizualnej projektu, przygotowywać szablonów stron, ani rozmawiać z grafikiem? Nie ma tragedii – wciąż znajdzie się coś dla ciebie. Mowa tutaj o projektach z obszaru “developers productivity”, czyli narzędziach dla programistów.

Wiele z nich nie dotyczy w żaden sposób tego, jak tworzymy stricte interfejs użytkownika. Dzięki nim mamy jednak możliwość tworzenia modularnego kodu (managery paczek, np. npm), używania eksperymentalnych funkcjonalności języka (kompilatory, np. Babel), czy nawet pisania dla internetu w językach innych niż JS (TypeScript, Elm, Reason).

Co prawda w tym wypadku nie mówimy wprost o front-endzie, ale raczej o tworzeniu czegoś “dla front-endu”. Niemniej jednak wartość tego typu narzędzi jest naprawdę nieoceniona. W jaki sposób możesz współtworzyć takie projekty? Podpowiedzią jest tutaj Open Source, i kontrybucje do projektów za pośrednictwem np. portalu GitHub. Jeśli na etapie na którym jesteś jest to dla ciebie poprzeczka zawieszona zbyt wysoko, to zawsze możesz zacząć od tworzenia prostych narzędzi automatyzujących codziennie czynności związane z front-endem.

To co z tym frontem?

Oczywiście pytanie w tytule tego posta było nieco prowokacyjne. W dzisiejszych czasach nikomu nie trzeba tłumaczyć się z tego, czy front-end to już programowanie, czy jeszcze hobby.

Z powodu coraz większej mocy obliczeniowej urządzeń którymi się posługujemy, coraz więcej akcji może dziać się po stronie klienta. Na tym właśnie rośnie cały świat front-endu. Największe firmy na świecie inwestują ogromne pieniądze w to, żeby ich developerzy mogli pracować nad takimi projektami jak Angular czy React. Ionic, czy React Native, wywodzące się wprost od technologii front-endowych, kwestionują istniejący porządek w świecie aplikacji mobilnych. Web rośnie każdego dnia – w dzisiejszych czasach żadnego użytkownika przeglądarki internetowej nie dziwi korzystanie z lokalizacji, wysyłanie powiadomień push czy dostęp do aparatu. Co za tym idzie, role w projektach i obowiązki front-end developerów również rosną. Dlatego właśnie zdecydowanie nie żałuję wyboru, który podjąłem kilkanaście miesięcy temu.

A jakie jest wasze zdanie na temat front-endu? Czy prawdziwe programowanie zaczyna się poniżej tej warstwy? Czy JavaScript to żart, czy jednak język warty zainteresowania? Co was najbardziej irytuje w kontaktach z front-endowcami? Zapraszamy do dyskusji!

  • Jakub

    Bardzo fajny artykuł 😀 Zastanawia mnie tylko dlaczego mówiąc front-end mówimy tylko o technologiach web, przynajmniej z czymś takim się spotykam na co dzień…(jestem świeżakiem w świecie programowania) Co z pozostałymi technologiami? Czy istnieje podział na np wpf/uwp/android/xamarin front-end i back-end developera?

    • Przemek Smyrdek

      W szerokim rozumieniu, tak jak np. Wikipedia podaje, https://en.wikipedia.org/wiki/Front_and_back_ends front-end może być rozumiany jako warstwa prezentacji. Przyjęło się jednak, że “front-end” = web, a technologie o których ty mówisz są wymienione właśnie z nazwy. Jeszcze nie spotkałem się z nikim przedstawiającym się jako Front-End Developer, które po prostu robi widoki do WPFa albo Androida (może to kwestia otoczenia w którym jestem).