The Great Divide to esej Chrisa Coyiera, napisany w styczniu 2019 roku. Próbuje on wyjaśnić nowe zjawisko, które pojawiło się w społeczności front-endowej. A wygląda następująco: po jednej stronie mamy programistów, którzy bardzo dobrze posługują się JavaScriptem, a po drugiej programistów, którzy bardzo dobrze znają HTML-a, CSS-a, dostępność i projektowanie stron internetowych. Mimo iż obie grupy nazwą same siebie front-endowcami, to tak naprawdę nie mają takich samych zainteresowań czy umiejętności. Według Chrisa "nie mają o czym rozmawiać".
Istnieją jednak też inne podziały, które czają się w świecie oprogramowania poza front-endem. Niektóre z tych podziałów istnieją od dziesiątek lat, a inne od momentu, gdy uknuto termin "inżynieria oprogramowania", jakieś 50 lat temu. Poza tym istnieje jeden podział. Taki, który z perspektywy żadnego rozsądnego człowieka nie powinien istnieć.
Ten tekst będzie mówił o ważnych podziałach w web developmencie i o wpływie, które mogą mieć na zespoły, społeczności i organizacje. Istnieją starsze i mocniejsze podziały niż te, które widzisz obecnie w społeczności front-endowej
Front-end a back-end
Istnieje wielu webowych developerów, którzy potrafią tworzyć wspaniałe strony internetowe. Z jednej strony mamy ludzi wysoko wykwalifikowanych w zakresie działania przeglądarek - programistów front-endowych, a z drugiej - ludzi wykwalifikowanych w zakresie działania serwera - programistów back-endowych.
Idea front-endu w kontekście sieci pojawiła się jeszcze przed pojawieniem się jQuery. W tym czasie tworzyliśmy strony internetowe wewnątrz tabel i musieliśmy wymyślać kreatywne haki CSS-a do obsługi wszechmocnego IE 6. Choć wydaje się, że było to dawno temu, praktyka front-endu jest stosunkowo nowa, mając ledwo 20 lat na karku. Z drugiej strony back-end ma tyle lat, co pierwsze komputery.
Jeśli budujesz aplikacje back-endowe, uczysz się niezliczonych podstaw, niezbędnych do tworzenia oprogramowania, które inteligentni programiści odkryli już kilkadziesiąt lat temu. Praktyki te nie są zgłębiane przez programistów, którzy są bardziej zainteresowani technologiami front-endu. To działa w dwie strony. Jeśli jesteś przyzwyczajony do budowania aplikacji front-endowych, uczysz się podstaw działania przeglądarek, co nie zainteresuje back-endowców.
Back-endowych deweloperów nie obchodzi front-end. Front-endowych nie obchodzi back-end
Ten podział zainteresowań tworzy ogromną lukę wiedzy po obu stronach.
W przypadku społeczności IT taki podział uniemożliwia dzielenie się doświadczeniami i wiedzą. Utrudnia osiągnięcie znacznego potencjału w zakresie innowacji technologicznych.
Np. powiedzmy, że poszedłeś na meetup poświęcony back-endowym językom. Najprawdopodobniej spotkasz wyłącznie back-endowych deweloperów. “Kultura pogardy” wobec front-endowców to coś, co łatwo powstaje w takich warunkach.
Wyobraźmy sobie, że na tym samym spotkaniu jest kilku młodych programistów, którzy dopiero rozpoczynają swoją karierę w branży oprogramowania. Jeśli usłyszą negatywne opinie i zniechęcą się do front-endu, będą również gardzić wszystkim, co z tym związane, w przyszłości. Ta separacja tworzy środowisko, które jest w pewien sposób ograniczone, gdyż nie wykorzysta do swojej pracy potencjalnie przydatnych elementów z programowania front-endowego lub samej wiedzy specjalistów tej przeciwległej odnogi.
Z perspektywy organizacji, to zachęca każdy zespół do duplikowania logiki zarówno we front-endzie jak i back-endzie.
Np. masz przełącznik stanu na backendzie: “PENDING” i “CANCELLED”. Biorąc pod uwagę, że programiści front-end pracują niezależnie od siebie, jest bardzo prawdopodobne, że skończysz z tą samą logiką w kodzie front-endu. Później, jeśli zechcesz utworzyć nowy stan, będziesz musiał zmienić zarówno front-end, jak i back-end, zamiast zmieniać wszystko tylko w jednym miejscu.
Jeśli jesteś programistą front-end, zapewne tworzysz systemy z ciężkim kodem JavaScript po stronie klienta i lekkim kodem po stronie serwera. Jeśli jesteś backendowcem, tworzysz systemy z ciężkim kodem po stronie serwera i lekkim kodem po stronie klienta.
Poruszałem już ten temat w artykule, który pokazuje, jak separacja back-endu i front-endu może doprowadzić do pisania bezużytecznego kodu. Więcej przykładów możesz zobaczyć tutaj: Sepracja front-endu i irracjonalna miłość do zakręconych nawiasów.
Rozdzielenie front-endu i back-endu tworzy zachęty dla programistów do pracy w izolacji, powielania logiki i rozwijania wszystkiego jedynie w przeglądarce lub jedynie na serwerze
Operacje infrastrukturalne a rozwoju produktów
Z jednej strony masz ludzi wysoko wykwalifikowanych w zakresie działania protokołów sieciowych i sprzętu, a z drugiej - w zakresie architektury oprogramowania i projektowania.
Jeśli masz większe zainteresowanie działaniem infrastruktury, masz tendencję do pozbawiania przywileju uczenia się zasad projektowania oprogramowania związanych z szybkim i zrównoważonym rozwojem produktu. Zwykle koncentrujesz się na komputerach i wyzwaniach technologicznych związanych z ich działaniem: wysoka dostępność.
Skupianie się na tym, aby komputery działały, pomaga w nauce, w projektowaniu niezawodnego oprogramowania i stawia na obserwowalność sprzętu. Nie pomaga to jednak w nauce projektowania systemów, które mogą zapewnić dostępność z perspektywy użytkownika. Np. nie ma sensu, aby serwer był gotowy do pracy, jeśli użytkownik musi oglądać obracające się kółko przez godzinę, by uzyskać to, czego chce. Z punktu widzenia użytkownika to jest awaria.
Twoją codzienną rutyną kodowania jako programisty Infrastructure Operations może być pisanie małych, samodzielnych skryptów Bash lub kodu infrastruktury, takiego jak Terraform. Dlatego uczenie się technik zautomatyzowanego testowania, takich jak TDD, nie ma większego sensu; nie ma też sensu uczenie się jak zmienić swój projekt, aby był bardziej testowalny.
Jeśli jesteś bardziej zainteresowany rozwojem produktu, to może brakować Ci wiedzy o podstawowych zasadach fizyki. Łatwo wpadasz w 8 błędnych przekonań o obliczeniach rozproszonych. Masz tendencję do optymalizacji pod kątem świetnych zasad projektowania i programowania, które mogą zwiększyć łatwość utrzymania i zmniejszyć koszty programowania (SOLID, XP, Connascence, Cohesion). Jednakże tracisz również możliwość poznania wyzwań związanych z fizycznymi granicami, w których komputery działają w realnym świecie. Jak to mówią: "Chmura nie istnieje, to tylko czyjś komputer", a komputer znajduje się gdzieś w świecie rzeczywistym.
Podział na infrastrukturę i rozwój produktu stwarza zachęty dla programistów, aby nie starali się zrozumieć fizycznych wyzwań związanych ze sprzętem, a dla działu operacji, by nie rozumieli ekonomicznych kosztów oprogramowania.
User Experience a Front-end Development
Z jednej strony mamy ludzi o dużych umiejętnościach w zakresie tworzenia user experience i wizualnego projektowania systemu, a z drugiej ludzi o dużych umiejętnościach w zakresie używania HTML-a, CSS-a i JavaScriptu w celu tworzenia “żywej” strony internetowej dla produkcji.
Z punktu widzenia projektanta, buduje on przepływ użytkowników w oparciu o informacje zwrotne od klientów wraz z artefaktami wizualnymi w celu dopasowania ich do brandingu firmy. Jednakże, kiedy przekazują to programistom front-endowym, programiści narzekają, że końcowy rezultat nie pasuje do ich wewnętrznej biblioteki komponentów. Skarżą się również na to, że elementy zaangażowane w zamierzony przepływ od projektanta są trudne i kosztowne w produkcji. Rezultat znacznie różni się od tego, co przewidział projektant.
Z punktu widzenia dewelopera, otrzymuję on piękny przepływ i design. Jednakże projekt wykazuje zerowe zrozumienie tego, jakie koszta związane są z jego rozwojem.
Niektóre komponenty nadają się do wielokrotnego użytku, ale projekt ich nie wykorzystuje. Zespół może zmienić niektóre części interfejsu użytkownika, ale innych nie może nawet dotknąć. Np. projektant może stworzyć prezentację onboardingową, która obejmuje wszystkie komponenty strony. Jednak projektant nie wie, że zespół kontroluje tylko jeden iframe wewnątrz głównej strony internetowej. Jest technicznie i politycznie niemożliwe, aby mieć na stronie onboarding, który prezentuje wszystkie jej komponenty bez przepisywania całego systemu.
Podział między UX i front-endem stwarza sytuację, w której deweloper narzeka na projektanta, a projektant na dewelopera
Istnieje wiele powodów, dla których powstały te podziały. Główną z nich jest to, że firmy i społeczności programistyczne opierają swoje role na technologii:
"front-end JavaScript developer."
"front-end HTML/CSS Developer."
"DevOps Engineer."
"back-end Developer."
"UX Designer."
Zamiast opierać swoje role na umiejętnościach i możliwościach biznesowych:
"Online Sales."
"Customer Recovery Department."
"Automated Billing."
"Employee Experience."
"Online Marketing."
Każdy uważa, że koszt, jaki jedna osoba musi ponieść, aby nauczyć się najważniejszych podstaw niezbędnych do rozwoju oprogramowania, jest zbyt wysoki. Z tego powodu rynek stwarza zachęty dla ludzi, aby szli na skróty, zdobywając konkretne specjalizacje w celu szybkiego znalezienia pracy i rozpoczęcia kariery.
Najszybszym sposobem wejścia na rynek pracy jest zrobienie specjalizacji
Podsumowując, istnieje wiele technologii dzielących rozwój oprogramowania, takich jak podział pomiędzy JavaScriptem i HTML-em w web dewelopmencie. Inne podziały to:
"back-end" i "front-end".
"Operacje" i "Rozwój produktu".
"UX Design" i "Front-end Development".
Dla nas, jako programistów, najważniejsze jest zrozumienie podstaw rozwoju oprogramowania, a nie koncentrowanie się wyłącznie na jednym stosie technologicznym. Pozwala to zobaczyć wszystkie granice tego, co jest możliwe, i co nie jest możliwe; zrozumieć kompromisy jednego podejścia technicznego nad drugim, w praktycznym kontekście biznesowym.
Kod, który piszesz w celu rozwiązania jakiegoś problemu, niesie ze sobą też inny cel. Celem jest wytworzenie wartości, a nie tylko napisanie kodu. To właśnie jest programowanie.
Dla firmy najważniejsze jest stworzenie kultury współpracy. Jeżeli praca, jaką mamy wykonać wymaga zaangażowania wielu ról, spróbujmy te role zbliżyć do siebie jak najbardziej - zbierzmy je razem w jednym pomieszczeniu, w jednym czasie, w jednym komputerze. Twórzmy kulturę wspólnego przeglądu kodu, programowania parowego i grupowego.
Jako programiści, musimy uczyć się podstaw, a jako firma - współpracy.
Poza tym wszystkim, co opisałem, istnieje jeszcze jeden podział, który ma miejsce w każdej dużej organizacji; podział, który nigdy nie powinien powstać - na tych, którzy tworzą oprogramowanie i tych, którzy go używają. To podział na deweloperów i klientów. Ale to już temat na inny tekst.
Oryginał tekstu w języku angielskim przeczytasz tutaj.
Cel i adresaci szkolenia
Zadaniem kursu jest przygotowanie Cię do podjęcia pracy w zawodzie Front-end Developera. Kompletne, 8-dniowe szkolenie ostało zaprojektowane tak, żeby przekazać Ci praktyczną i kompleksową wiedzę z obszaru środowiska developerskiego w zakresie metod tworzenia i testowania oprogramowania oraz obsługi różnych źródeł danych.
Czy to szkolenie jest dla Ciebie?
Tak, jeśli chcesz zacząć karierę w obszarze tworzenia stron www i zyskać kompetencje Front-end developera, które przygotują Cię do pracy na tym stanowisku. Pracujesz już jako developer i znasz podstawy JavaScript? Szkolenie pozwoli Ci ugruntować wiedzę z zakresu tworzenia Front-endu z użyciem nmp, node.js czy React oraz da szansę na zdobycie certyfikatu Front-end Certified Developer Sii.
Nie wymagamy wcześniejszego przygotowania ani doświadczenia, dlatego w szkoleniu mogą wziąć udział wszyscy zainteresowani pracą w tym zawodzie:
studenci i absolwenci różnych kierunków studiów,
osoby chcące się przekwalifikować,
osoby, które swoją przyszłość chcą związać z zawodem Front-end developera,
osoby, które chcą poszerzyć swoją wiedzę.
Dlaczego my?
Kompleksowość – uczestniczysz w unikalnym programie szkoleniowym na rynku, który w pełni przygotuje Cię do uzyskania kwalifikacji w zakresie programowania Front-end
– uczestniczysz w unikalnym programie szkoleniowym na rynku, który w pełni przygotuje Cię do uzyskania kwalifikacji w zakresie programowania Front-end Doświadczenie – pracujesz z wykwalifikowanymi trenerami pracującymi w zawodzie developera na co dzień, którzy potrafią przekazać praktyczną wiedzę oraz podzielić się bogatym doświadczeniem
– pracujesz z wykwalifikowanymi trenerami pracującymi w zawodzie developera na co dzień, którzy potrafią przekazać praktyczną wiedzę oraz podzielić się bogatym doświadczeniem Praktyka – uczysz się na konkretnych przykładach ze środowisk developerskich (case study), wykorzystując narzędzia i programy informatyczne
– uczysz się na konkretnych przykładach ze środowisk developerskich (case study), wykorzystując narzędzia i programy informatyczne Certyfikacja – po ukończeniu kursu masz możliwość uzyskania certyfikatu Front-end Certified Developer Sii potwierdzającego wiedzę oraz umiejętności w zakresie programowania w Front-end
– po ukończeniu kursu masz możliwość uzyskania certyfikatu Front-end Certified Developer Sii potwierdzającego wiedzę oraz umiejętności w zakresie programowania w Front-end Szansa na zdobycie zatrudnienia – jeśli jesteś osobą prywatną, zyskujesz możliwość odbycia stażu lub rozpoczęcia pracy w Sii po zrealizowanym szkoleniu
– jeśli jesteś osobą prywatną, zyskujesz możliwość odbycia stażu lub rozpoczęcia pracy w Sii po zrealizowanym szkoleniu Silna marka – szkolisz się z wiarygodnym, doświadczonym i rozpoznawalnym na rynku dostawcą szkoleń oraz największym pracodawcą w obszarze usług IT i inżynieryjnych w Polsce
Efekty szkolenia
Po ukończeniu szkolenia zdobędziesz podstawy teoretycznej i praktycznej wiedzy z zakresu tworzenia oprogramowania z użyciem HTML, CSS, JavaScript, node.js oraz React.
Twoje umiejętności:
instalacja i konfiguracja środowiska developerskiego
podstawy tworzenia stron www (HTML, CSS)
pisanie aplikacji w języku JavaScript
znaczenie i używanie node.js
npm – organizowanie kodu w moduły i pakiety
używanie biblioteki React.js
metody tworzenia i testowania oprogramowania
tworzenie skryptów automatyzujących zadania
obsługa różnych źródeł danych, zasady wywołań asynchronicznych
przetwarzanie struktur XML oraz JSON
podstawy baz NoSQL
Dodatkowo poznasz:
najlepsze praktyki oraz zaawansowane techniki
najczęściej popełniane błędy i przyczyny nieprawidłowości działania systemu
używanie narzędzi, technik i oprogramowania
Zakres szkolenia
Dzień 1
Instalacja i konfiguracja środowiska developerskiego
Wprowadzenie i zakres szkolenia
Podstawowe pojęcia
Podstawy HTML
Tagi i atrybuty HTML
DOM HTML
Podstawy programowania z użyciem DOM HTML
GIT – wersjonowanie, kontrola wersji
Strona HTML
Instalacja i konfiguracja środowiska developerskiego Wprowadzenie i zakres szkolenia Podstawowe pojęcia Podstawy HTML Tagi i atrybuty HTML DOM HTML Podstawy programowania z użyciem DOM HTML GIT – wersjonowanie, kontrola wersji Strona HTML Dzień 2
Podstawy CSS
Zastosowanie CSS i dynamiczna zmiana wyglądu strony
Obsługa zdarzeń z użyciem JavaScript i CSS
JavaScript
Wprowadzenie do programowana w JS
Podstawy JavaScript zmienne pętle typy danych funkcje wbudowane operujące na stringach, wartościach i liczbach Tablice JSON Tworzenie, pobieranie, iterowanie po obiektach Deklarowanie i parametry funkcji Funkcje anonimowe Funkcje strzałkowe ES6 (ECMAScript 6)
Podstawy CSS Zastosowanie CSS i dynamiczna zmiana wyglądu strony Obsługa zdarzeń z użyciem JavaScript i CSS Wprowadzenie do programowana w JS Podstawy JavaScript Dzień 3
Tablice Sortowanie (domyślne, własne comparatory) Map, Reduce i Filter Kolekcje (Map oraz Set)
Wskaźnik this i prototypy obiektów
Zakresy i domknięcia
Składanie funkcji
Asynchroniczność i wydajność
Tablice Dzień 4
npm – manager pakietów JavaScript
środowisko uruchomieniowe node.js
Testowanie przy pomocy node.js
Podstawy baz danych NoSQL
baza MongoDB
model danych
operacje CRUD (Create/Read/Update/Delete)
zapytania do bazy
npm – manager pakietów JavaScript środowisko uruchomieniowe node.js Testowanie przy pomocy node.js Podstawy baz danych NoSQL baza MongoDB model danych operacje CRUD (Create/Read/Update/Delete) zapytania do bazy Dzień 5
React.js
Struktura projektu
Komponenty
React Virtual DOM, elementy i JSX
React.js Struktura projektu Komponenty React Virtual DOM, elementy i JSX Dzień 6
Redux
Deployment aplikacji
Testowanie JEST
Redux Deployment aplikacji Testowanie JEST Dzień 7
Klasy
Stany i obsługa stanów
Komponenty bezstanowe
Promesy
Routing
Przygotowanie do egzaminu Front-end Certified Developer Sii
Projekt praktyczny – warsztat projektowy
Dzień 8
Projekt praktyczny – warsztat projektowy
Egzamin Front-end CD Sii
Informacje dodatkowe
Najbliższe terminy szkolenia
W dzisiejszych czasach mamy na rynku całe mnóstwo frameworków, bibliotek oraz narzędzi, które pomagają nam w procesie rozwoju oprogramowania. To jest szczególnie widoczne w świecie front-endu gdzie repozytoria GitHub czy NPM pękają w szwach od ilości dostępnych paczek. Nic dziwnego, że ktoś mniej doświadczony może czuć się w tym gąszczu narzędzi zagubiony. Dlatego też postanowiłem, że przyjrzę się bliżej temu tematowi i zaprezentuję Wam dziś nowoczesny stos technologiczny dla front-endu. Myślę, że najlepszą formą dla tego zagadnienia będzie zestawienie najbardziej, w mojej opinii, wartościowych narzędzi, bibliotek i frameworków.
Dlaczego dobrze jest wykorzystywać narzędzia wspierające development?
Jak wszyscy wiemy, każdy programista jest z zasady bardzo leniwą ale też pragmatyczną osobą. Dlatego też, zwykle stara się osiągnąć swój cel jak najmniejszym możliwym wysiłkiem. Z tego powodu programiści z całego świata codziennie starają się stworzyć narzędzia, które ułatwią im ich pracę. Na szczęście wielu z nich postanawia też podzielić się efektami swojej pracy ze społecznością… Open Source, wiecie, rozumiecie… W efekcie mamy szczęście żyć świecie, w którym możemy się skupić przede wszystkim na byciu kreatywnym. Możemy więc po prostu pisać nasze “kody”. Wszystko inne może być załatwione z użyciem odpowiednich narzędzi!
Jak możemy skategoryzować nowoczesny stos technologiczny dla front-endu?
Aby odpowiednio zestawić nowoczesny stos technologiczny dla front-endu postanowiłem zaproponować poniższe kategorie. Są to narzędzia, biblioteki i frameworki, które są obecnie najpopularniejsze w pracy front-end developera:
edytory / IDE
systemy kontroli wersji
menedżery pakietów
lintery
pre-procesory CSS
pre-procesory JavaScript
minifikatory
loadery modułów / bundlery
narzędzia do automatyzacji zadań
frameworki CSS
frameworki JavaScript
W dalszej części tego artykułu znajdziesz więcej informacji na temat każdej z powyższych grup. Dla każdej z tych kategorii postaram się też podać ich najbardziej reprezentatywnych przedstawicieli. Jednakże pamiętaj, że powyższa lista to tylko moja subiektywna propozycja. Nie jest wcale powiedziane, że koniecznie należy wykorzystywać narzędzia ze wszystkich tych grup, we wszystkich Twoich projektach. Tak na prawdę powinno to być zawsze podyktowane Twoimi potrzebami w danej sytuacji.
Edytory / IDE
Zanim zaczniemy pracę z front-endem musimy zdecydować jakiego narzędzia będziemy używać do pracy z kodem. Generalnie stoimy przed wyborem pomiędzy prostymi edytorami tekstu a pełnymi IDE (z angielska “Integrated Development Environment” czyli po naszemu “Zintegrowane Środowisko Programistyczne”). Edytory zwykle posiadają wiele przydatnych funkcji, jak na przykład kolorowanie składni czy podpowiadanie kodu. Mają też bardzo często możliwość rozszerzania za pomocą wtyczek.
Z drugiej strony barykady mamy narzędzia typu IDE. Z założenia posiadają one o wiele więcej funkcji. Do najważniejszych z nich należą zaawansowane funkcje wspierające refaktoring, sygnalizowanie potencjalnych błędów czy zaawansowana nawigacja pomiędzy plikami. Zwykle jednak jest to wszystko obarczone ich wolniejszą pracą, a co za tym idzie większymi wymaganiami sprzętowymi.
Z trzeciej jeszcze strony, dzisiejsze edytory dzięki wspomnianym wtyczkom (często open source’owym) można dość mocno rozbudować. Dzięki temu na upartego da radę zbliżyć je funkcjonalnością do IDE.
Poniżej znajdziesz listę najpopularniejszych obecnie edytorów oraz IDE:
Systemy kontroli wersji
Jeśli chcesz się zabezpieczyć przed niespodziewaną utratą swojego kodu lub, co ważniejsze, ułatwić współpracę nad jednym projektem większej liczbie osób powinieneś rozważyć użycie systemu kontroli wersji. Narzędzie takie pozwala nam na przechowywanie kodu w ogólnie dostępnym repozytorium. Oczywiście ogólnie dostępnym dla członków zespołu… Dzięki temu możliwe jest jego łatwe współdzielenie. System kontroli wersji posiada też wsparcie dla łączenia (ang. “merge”) naszych zmian ze zmianami innych programistów. Kolejną ważną zaletą tego typu narzędzi jest możliwość cofnięcia zmian do konkretnej, wybranej przez nas wersji. Przydaje się to na przykład kiedy okaże się, że obecna wersja zawiera zbyt dużo błędów.
Poniżej lista najczęściej wykorzystywanych obecnie systemów kontroli wersji:
Dodatkowo muszę dodać, że Git obecnie dzieli i rządzi. Prawdopodobnie dzięki istnieniu GitHub’a czyli najbardziej popularnego, ogólnie dostępnego repozytorium Git, w którym znajduje się większość tworzonych obecnie projektów open source.
Menedżery pakietów
Powoli przechodzimy już do sedna czyli tego co każdy nowoczesny stos technologiczny dla front-endu zawierać powinien… W celu zapewnienia zawsze najświeższych wersji narzędzi, bibliotek i frameworków powinniśmy pomyśleć o zastosowaniu menedżera pakietów. Jak sugeruje nazwa, menedżer pakietów to narzędzie, które pozwala nam zarządzać pakietami w naszym projekcie. Pozwala nam na pobieranie, aktualizację i usuwanie ich z projektu. Potrafi on też rozwiązywać zależności pomiędzy nimi dzięki czemu zawsze mamy wszystkie pakiety które są nam potrzebne.
Poniżej najpopularniejsze obecnie menedżery pakietów dla front-endu:
Powyższa lista menedżerów pakietów wymaga oczywiście komentarza…
Po pierwsze Yarn jest czymś zupełnie nowym na rynku i wydaje się, że może być małą rewolucją. Zresztą pisałem o nim ostatnio na blogu.
Po drugie Yarn, w przeciwieństwie do NPM i Bowera nie posiada własnego repozytorium pakietów. Jeśli więc się na niego zdecydujesz, będziesz musiał prawdopodobnie i tak używać NPM jako repo.
Po trzecie Bower powoli już odchodzi w niebyt. Początkowo zamysł był taki, że NPM jest dedykowany światu node.js a Bower jest przeznaczony dla świata front-endu. Z biegiem czasu zaczęto od tego odchodzić i najświeższe paczki, chociażby dla ekosystemu React znajdziesz właśnie w NPM a nie w repozytorium Bowera.
Jak więc widzisz, dzięki pojawieniu się Yarna jesteśmy obecnie na małym rozdrożu… Ciekawe w którą stronę to wszystko pójdzie?
Lintery
Lintery to kolejna grupa narzędzi wspierających pracę front-end developera. Z nimi na pokładzie możemy monitorować jakość naszego kodu - zarówno JavaScript jak i CSS. Posiadają one możliwość zdefiniowania zasad, do których wszyscy w projekcie mają się stosować. Dzięki tym zasadom lintery mogą skanować nasz kod i wyświetlać błędy i ostrzeżenia jeśli jakiś jego kawałek nie spełnia tych zasad.
Jak wspomniałem istnieją lintery zarówno dla JavaScript jak i dla CSS. Poniżej krótka lista tych najczęściej stosowanych:
Do listy trzy uwagi…
Po pierwsze: JSHint jest forkiem JSLinta i z biegiem czasu stał się tym bardziej popularnym i powszechnie używanym linterem JavaScript.
Po drugie: jeśli używasz pre-procesora CSS to pewnie nie będziesz go potrzebować… Pre-procesor i tak generuje CSS za Ciebie a do tego sam pilnuje swojej składni.
ESLint jest linterem badającym kod napisanym w ES6. Jeśli zaczynasz nowy projekt to prawdopodobnie właśnie z niego powinieneś skorzystać.
Pre-procesory CSS
Moim zdaniem pre-procesor CSS to element, który każdy nowoczesny stos technologiczny dla front-endu powinien zawierać! Pre-procesor CSS to narzędzie, które sprawia, że praca z arkuszami stylów jest przyjemna. Rozszerzają one znacznie składnię CSS dodając do niego komendy, dzięki którym staje się on znacznie bardziej re-używalny. Redukuje to liczbę powtórzeń kodu co jest przecież zmorą CSS. Poza tym dodają one możliwość modularyzacji kodu. Moduły te możemy ładować warunkowo wtedy, kiedy na prawdę ich potrzebujemy.
Poniżej lista najpopularniejszych pre-procesorów CSS:
Sass/SCSS jest obecnie najbardziej popularnym z pre-procesorów CSS. LESS powoli traci na znaczeniu i jest polecany raczej dla mniejszych projektów. Osobiście bardzo podoba mi się Stylus - jego składnia jest bardzo czysta. Pozostałych, szczerze mówiąc, nie używałem ale istnieją na rynku więc jeśli szukasz rozwiązania dla siebie to możesz również wziąć je pod uwagę.
Pre-procesory JavaScript (“transpilery”)
Tak jak pre-procesory CSS tak i pre-procesory JavaScript także zmieniają składnię języka JavaScript. Dzięki temu mamy możliwość pisania kodu, w bardziej przyjaznym języku, który później transformowany jest do rzeczywistego kodu JavaScript. Pre-procesory JavaScript obecne w tym momencie na rynku mają różne cele i dlatego ciężko je tak na prawdę porównywać. Każdy z nich ma inne zalety ponieważ ich autorom przyświecały inne cele. W zasadzie to zasługują one na osobne posty, a nawet na cykle postów…
Poniżej znajdziesz trzy najważniejsze obecnie pre-procesory JavaScript obecne w świecie front-endu:
Osobiście preferuję czysty JavaScript dlatego też jak dla mnie, najbardziej interesujący jest Babel. Pozwala on na pisanie kodu w nowej wersji JavaScript czyli ECMAScript 6 / ECMAScript 2015. Jest to istotne ponieważ wsparcie dla nowego JavaScript przez przeglądarki jest na chwilę obecną mizerne. Sukcesywnie dodawana jest także obsługa nowych “ficzerów” języka, które mają pojawiać się w kolejnych jego odsłonach.
TypeScript, dzięki pojawieniu się drugiej wersji frameworka Angular zyskuje obecnie znaczną popularność. Główną ideą tego pre-procesora jest dodanie do języka JavaScript statycznego typowania. Oprócz tego, w zasadzie jako bonus, TypeScript zapewnia też wsparcie dla ES6/2015, więc mogą to być “dwie pieczenie na jednym ogniu”…
CoffeeScript nigdy nie używałem ale tak na prawdę jest to po prostu pre-procesor, który pozwala na pisanie skryptów za pomocą zmienionej, przyjemniejszej składni.
Reasumując, obecnie stoimy przed wyborem: TypeScript czy Babel… Wszystko zależy chyba od typu projektu i wymagań. Pisałem o tym co nieco we wpisie na temat wpływu Angulara 2 na ekosystem React.
Minifikatory
Kolejna niezwykle ważna sprawa jeśli chodzi o stos technologiczny dla front-endu… Dla zapewniania wydajności naszych rozwiązań, nie powinniśmy zapominać o minifikacji kodu JavaScript oraz CSS. Czym jest minifikacja? To proces transformacji kodu, który jest sformatowany tak aby łatwo było go czytać na taki, który jest możliwie krótki. W efekcie dostajemy jedną linijkę kodu, w którym zmienne mają długość jednego znaku a wszystkie białe znaki są usunięte. Dzięki temu plik taki zajmuje mniej miejsca i jest ładowany szybciej przez przeglądarkę. W końcu dla kompilatora nie ma znaczenia czy kod jest ładnie sformatowany czy też nie.
Poniżej dwa przykłady takich minifikatorów:
Loadery modułów / Bundlery
Przedstawione przed chwilą minifikatory powoli przestają być stosowane bezpośrednio. Ich rolę przejmują bardziej rozbudowane narzędzia czyli tak zwane bundlery lub inaczej (wcześniej) loadery modułów. Generalnie loadery modułów powstały zanim pojawił się ES6 z wbudowaną w język obsługą modułów. Dlatego też ich głównym celem była modularyzacja kodu JavaScript. Jako efekt uboczny ich działania była możliwość bundlowania kodu do pojedynczego pliku wynikowego oraz jego minifikacja (nadal wykorzystuje się przedstawione wcześniej narzędzia ale niejawnie). Obecne rozwiązania skupiają się przede wszystkim na bundolowaniu kodu w oparciu o moduły ES6. Zapewniają one jednak kompatybilność wstecz dlatego możemy nadal korzystać z modułów pisanych w stylu AMD lub CommonJS.
Poniżej kilka przykładów takich loaderów modułów / bundlerów:
Obecnie najpopularniejszym i powszechnie stosowanym rozwiązaniem jest Webpack. Pisałem już o nim co nieco na blogu: na przykład o podstawach jego konfiguracji. Myślę, że na pewno warto go znać.
Narzędzia do automatyzacji zadań
Stos technologiczny dla front-endu nie może się obejść bez narzędzi do automatyzacji zadań! “Task runnery” to narzędzia pozwalające łatwo automatyzować wykonywanie różnego rodzaju zadań związanych z programowaniem front-endu. Dzięki nim możemy na przykład automatyzować analizę kodu przez lintery za każdym razem gdy jakiś plik `*.js` się zmieni. Można ich też używać do uruchamiania pre-procesorów JavaScript i CSS oraz minifikatorów.
Poniżej przykłady takich narzędzi:
Grunt
Gulp
Webpack + NPM scripts
Grunt powoli odchodzi już do lamusa. Gulp jest obecnie znacznie bardziej popularny. Wszystko dzięki odmiennej zasadzie działania opierającej się na strumieniach danych zamiast zapisywaniu wszystkiego do tymczasowych plików.
Na liście znalazł się też “Webpack + NPM scripts”. Nie bez powodu ponieważ, przynajmniej w świecie React, jest to bardzo często spotykane połączenie. Webpack, dzięki wsparciu dla “loaderów” ma bardzo duże możliwości automatyzacji. Wsparty skryptami NPM umożliwia pozbycie się Grunta/Gulpa bez szkody dla projektu.
Frameworki CSS
Wydaje mi się, że nie jest to coś co musi koniecznie znaleźć się w Twoim stosie technologicznym… Warto jednak o tym wspomnieć ponieważ są sytuacje gdzie frameworki CSS są nieocenione. Ogólnie rzecz biorąc założeniem frameworków CSS jest wsparcie dla tworzenia responsywnego HTML’a z użyciem predefiniowanych klas CSS. Dostarczają one nam zestaw klas, które możemy użyć do budowania layoutu ale też elementów na stronie takich jak formularze, menu itp. Minusem może być to, że zwykle nie wykorzystujemy większości z dostępnych klas a mimo to, cały pakiet sporo “waży”. Dlatego zawsze trzeba rozważyć, czy użycie frameworka CSS jest zasadne!
W zasadzie wśród frameworków CSS króluje Bootstrap ale są też dla niego alternatywy:
Tak na prawdę tych alternatyw jest na prawdę sporo - sprawdź na przykład tutaj. Istnieje więc szansa, że znajdziesz coś co spełni Twoje wymagania, a jednocześnie wydajność projektu mocno nie spadnie…
Frameworki JavaScript
No i dobrnęliśmy do najważniejszego elementu jaki posiadać powinien każdy stos technologiczny dla front-endu. Zwykle każdy większy front-endowy projekt musimy oprzeć na jakimś framewoku JavaScript. Framework taki może nam dostarczyć narzędzi do łatwej modularyzacji rozwiązania i zapewnić “separację zainteresowań” (ang. separation of concerns - nie wiem jak to lepiej przetłumaczyć…). Dotychczas frameworki JavaScript było w mniejszym lub większym stopniu implementacją wzorca MVC lub MVVM. Ostatnio wszystko odwróciło się do góry nogami i obecnie skupiamy się na budowaniu interfejsów w oparciu o niezależne komponenty.
Poza tym frameworki JS możemy też podzielić na te, które dostarczają nam wszystko co potrzeba do budowania aplikacji oraz na te, które zostawiają nam wolną rękę w wyborze bibliotek. Dlatego też musimy brać to pod uwagę przy wyborze frameworka. Jeśli mamy dowolność, zawsze możemy wymienić jakiś element projektu na inny. Z drugiej strony jeśli framework dostarcza wszystko co potrzeba, to prawdopodobnie jest to dopracowane i nie trzeba będzie z tego rezygnować.
Poniżej starsze frameworki, oparte na MVC lub MVVM - wciąż są rozwijane ale zapewne prędzej czy później o nich zapomnimy:
Z drugiej strony frameworki oparte na komponentach to przyszłość front-endu więc pewnie lepiej jest postawić właśnie na nie:
Jak widzisz, przykład z React zawiera więcej elementów. To dlatego, że sam React jest tylko biblioteką. W połączeniu jednak z paroma dodatkowymi elementami staje się pełnoprawnym frameworkiem JavaScript. To samo tyczy się Vue - tutaj również mamy dowolność w wyborze bibliotek współpracujących. Niestety nie mam dużej wiedzy na temat tego frameworka, stąd trzy kropki… Jego autorzy jednak, pomyśleli o takich jak ja i napisali ciekawy artykuł pokazujący różnice pomiędzy Vue i innymi rozwiązaniami. Myślę, że warto się z nim zapoznać.
Jak widzisz, stos technologiczny dla front-endu ma całkiem sporo do zaoferowania jeśli chodzi o swój najważniejszy aspekt czyli frameworki JavaScript.
Stos technologiczny dla front-endu - podsumowanie
Nowoczesny stos technologiczny dla front-endu to jak widać na prawdę spora ilość różnego rodzaju narzędzi, bibliotek i frameworków. Z jednej strony może być ciężko się w tym wszystkim połapać. Z drugiej strony, bez tego nasze życie było by znacznie trudniejsze. Dlatego też zawsze warto poświecić trochę czasu na początku projektu i dobrze przemyśleć jego stos technologiczny. Te decyzje mogą później zaprocentować w wydajności programistów i łatwości dostarczania nowych “ficzerów”.
Leave a Comment