Wypróbuj

Nozbe - get things done

i zwiększ swoją produktywność

Nowoczesny stos technologiczny dla front-endu

6

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 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”.

CHCESZ DARMOWEGO E-BOOKA?

Jeśli chcesz otrzymać mojego e-booka: Rozmowa Kwalifikacyjna - pytania z podstaw JavaScript zostaw mi swój e-mail:

Oprócz tego co poniedziałek dostaniesz maila z listą moich wpisów z poprzedniego tygodnia!

  • Paweł Tabisz

    Do edytorów warto dodać Visual Studio Code

  • Przy linterach warto do kompletu przy JSHint dorzucić JSCS (do sprawdzania codestyle’u). No i ESLint nie jest wyłącznie dla ES6. Warto dodać też, że zespoły JSHinta i ESLinta połączyły się i w ostateczności ma zostać wyłącznie ESLint.

    Przy preprocesorach brakuje niesamowicie popularnego ostatnio PostCSS. A przecież praktycznie wszyscy go używają/używali (Autoprefixer ;)).

    Przy transpilerach jakoś średnio bym powiedział, że CoffeeScript jest popularne. Większość go nienawidzi lub nie jest nim zainteresowana: http://stateofjs.com/2016/flavors/

    Przy minifikatorach brakuje Babili od Babela i Google Closure Compiler. A to bardzo poważni gracze w tym sektorze!

    Wśród bundlerów brakuje rollupa i… Google Closure Compilera 😉

    Przy task runnerach nie rozumiem natomiast połączenia Webpacka z npm (npm, nie NPM!) scripts (tzn. rozumiem, bo popularne itd., ale… a, wiadomo, o co chodzi!). Webpacka nigdy nie użyłem, npm scripts używam codziennie.

    > Poniżej starsze frameworki, oparte na MVC lub MVVM – wciąż są rozwijane ale zapewne prędzej czy później o nich zapomnimy:

    Wrzucenie tu Embera to IMO jakieś nieporozumienie. Zwłaszcza, że część rozwiązań, które dzisiaj są standardami (np. odkrycie na nowo server-side rendering) to zasługi właśnie tego frameworka. No i nie bardzo rozumiem podział, bo przecież taki Angular 1.x (1.5+ zwłaszcza) również jest komponentowy.