Programowanie aplikacji webowych jest jedną z najbardziej dynamicznie zmieniających się dziedzin IT. Można żartować, że podczas pisania tego zdania powstał nowy framework JS.

Właśnie, frameworki i biblioteki JS. Ręka w górę ten, który nie potrafi wymienić chociaż jednego takiego narzędzia. React, Angular, Ember, Meteor, Mithril, Polymer, Aurelia, VanillaJS… Jak to śpiewał pewien mądry człowiek We’re gonna build a framework.

Można by było zadawać sobie pytanie, dlaczego obecnie powstaje tyle narzędzi, a przede wszystkim – skąd to się wzięło? Poniżej przygotowałam krótką oś czasu z wybranymi pozycjami w historii programowania webowego:

Przez wiele lat strony WWW (bo trudno było je jeszcze nazwać aplikacjami) istniały sobie w cieniu ich desktopowych kuzynów. Zmieniło się to wraz z powstaniem Flasha i CSS, które umożliwiły tworzenie efektownych i estetycznych treści. Potem pojawiły się blogi i systemy CMS (takie jak WordPress) umożliwiające tworzenie dynamicznie generowanych treści przez użytkowników – weszliśmy w Web 2.0. Jednocześnie wciąż było nie do pomyślenia, aby aplikacje webowe były w stanie zastąpić te napisane w Javie i C++.

Przepraszam za dygresję: właśnie, Java. Write once, run everywhere. Ośmielę się powiedzieć, że webdev osiągnął to, czego Java w desktopach nie zdołała.

Wracając do tematu: były blogi, wiki i CMS, strony z mnóstwem gradientów, pastelowymi kolorami, Bootstrap… A potem na rynek weszły smartfony i Android. Dokonały się wtedy 2 typy zmian. W designie kluczowa okazała się responsywność – nagle niesamowicie ważna stała się czytelność naszego projektu na każdym rozmiarze ekranu. Nastąpiło wycofanie się z gradientów i tekstur do tzw. flat design – jednolitych kolorów na białym tle. Z kolei w przestrzeni samego tworzenia aplikacji zaszły jeszcze większe zmiany.

No dobrze, co z tym wspólnego ma Angular?

Przyznaję się, zagalopowałam się ze stwierdzeniem, że to smartfony wpłynęły na rozwój aplikacji webowych. Jednym z powodów były media społecznościowe.

Facebook został założony jeszcze w epoce Web 2.0. Najpopularniejszą biblioteką JS używaną wtedy do ułatwienia sobie tworzenia aplikacji było jQuery. Wyobraźmy sobie teraz, że trzeba stworzyć z użyciem jQuery olbrzymią aplikację, która wiele funkcjonalności musi obsługiwać po stronie klienta, zamiast ograniczać go, jak do tej pory, do wyświetlania z prostymi efektami, w zespole składającym się z kilku mniejszych, łącznie około 30 osób. Olbrzymia aplikacja frontowa, gigabajty przesyłanych danych, wielka korporacja, mnóstwo ludzi…

Należało sprowadzić programowanie FrontEndu do formy, w jakiej istniało programowanie BackEndu, umożliwiające podział kodu na zespoły. I tak w Google powstał AngularJS, Facebook stworzył Reacta… i tak poszło. Jednocześnie pojawił się nowy buzzword, określający nazwę typu aplikacji tworzonych z użyciem frameworków i bibliotek: SPA.

Czym jest SPA i co wynika z niej dla frameworków chciałabym opisać w osobnym poście, przejdźmy do samych narzędzi.

Z kolei jeśli chcecie wiedzieć więcej na temat historii Sieci, zapraszam na History of the Web i Evolution of the Web.

Po co są frameworki w JS?

Przede wszystkim umożliwiają podział kodu ze względu na funkcję, którą ma pełnić i zawartość do wyświetlenia. Jeśli wiecie, czym jest wzorzec projektowy MVC, możecie pominąć następny akapit. A jeśli nie…

Model-View-Controller (pol. Model-Widok-Kontroler) – wzorzec architektoniczny służący do organizowania struktury aplikacji posiadających graficzne interfejsy użytkownika. — Wikipedia

W skrócie dzielimy nasz kod na 3 podstawowe funkcjonalności:

• Model – CO wyświetlamy, z czego składają się nasze dane, jaka jest logika aplikacji
• Widok – JAK wyświetlamy model, czyli szablony
• Kontroler – W JAKI SPOSÓB model i widok powinny zareagować na to, co robi użytkownik

Dzięki takiemu podziałowi można oddzielić kod zajmujący się logiką od tego, który zajmuje się wyświetlaniem. Najpopularniejsze frameworki webowe są typu MVC. Przykładowo w Angularze Model i Kontroler pisane są w TypeScripcie, a sam widok w HTML i CSS. Kod staje się bardziej czytelny i łatwiejszy do późniejszego rozwoju.

W czym jeszcze pomagają frameworki i biblioteki:

• Podział kodu na komponenty sprawia, że można oddzielić treść o różnym przeznaczeniu (typu LoginComponent, DashboardComponent), a także łatwo użyć tego samego szablonu w wielu miejscach
• Przyspieszenie pisania z użyciem gotowych rozwiązań
• Podział kodu na zespoły (X pisze komponent A, Y pisze komponent B)

W czym nie pomagają:

• Potrzeba więcej czasu na rozpoczęcie pisania
• Przy mniejszych aplikacjach tworzenie z użyciem frameworka może wyglądać jak użycie koparki do przesadzenia tulipana

Którego mam się nauczyć?

Najpierw trzeba sobie odpowiedzieć na pewne pytanie.

Brzmi ono:

Czy znam JavaScript na tyle dobrze, żeby poruszać się w nim bez frameworka?

Odpowiedź: NIE

Nie ucz się żadnego.

Wiem, że może to zabrzmieć jak herezja, a ty jesteś ambitnym już-zaraz-juniorem, a każda firma w pracy wymaga jakiegoś frameworka, wręcz wstyd się bez niego pokazać.

Tylko żadne ułatwienie nie da ci tyle wiedzy na temat języka, co sam język. Framework jest narzutem, nakładką. Wykorzystuje mechanizmy, które w tym języku już istnieją. A JS jest, przynajmniej na tle popularnych języków obiektowych i orientowanych obiektowo, mocno nietypowy. Eventy, listenery, Promises, callbacki, Observable… Dopóki nie jesteś w stanie w miarę pewnie się w nich poruszać (powtarzam, w miarę! Nikt nie oczekuje od Ciebie wiedzy seniora, żebyś w ogóle zasiadł do Angulara), framework ukryje przed tobą funkcjonalności, o których nawet nie wiesz, że istnieją.

Dodatkowo w sytuacji, w której narzędzie wysiądzie (co się zdarza nawet przy najlepiej testowanym kodzie), łatwiej ci będzie zorientować się, co właściwie jest powodem błędu. I jak można ową niedogodność obejść lub naprawić.

Odpowiedź: TAK

W takim razie do zobaczenia w następnym poście z serii, w którym porównam ze sobą trzy najpopularniejsze narzędzia i wyjaśnię, gdzie najlepiej ich używać.