Czy opłaca się startować z nową aplikacją w Angularze 1.5? [“NG 1.5 z placu boju” 1/7]

Ten post to 1-sza część serii “Angular 1.5 z placu boju”, prezentującej architekturę opartej na komponentach, “gotowej na NG 2” aplikacji w Angularze 1.5, nad którą pracujemy.

Wprowadzona w Angularze 1.5 metoda module.component() może wydawać się kosmetycznym dodatkiem, jednak podejście, które ta metoda promuje (a które wykorzystujemy “do oporu”) owocuje zupełnie innym typem architektury niż opisywana w większości “klasycznych” tutoriali do Angulara, mam więc nadzieję, że uda Ci się na bazie naszych doświadczeń paru rzeczy dowiedzieć.

Spis Treści:

• Czy opłaca się startować z nową aplikacją w Angularze 1.5? [TEN POST]
• Aplikacja w Angularze 1.5 jako drzewo komponentów [WKRÓTCE]
• Komunikacja pomiędzy komponentami w Angularze 1.5 [WKRÓTCE]
• Elastyczna struktura projektu w Angularze 1.5 (architektura “fraktalna”) [WKRÓTCE]
• Pisanie projektu w Angularze 1.5 w ES6/ES2015 [WKRÓTCE]
• Testowanie jednostkowe komponentów Angulara 1.5 – szczegółowy przewodnik [WKRÓTCE]
• Testy E2E opartej na komponentach aplikacji w Angularze 1.5 [WKRÓTCE]

Kontekst

Na początku roku (w połowie stycznia) mieliśmy rozpocząć zupełnie nowy, świeży projekt. Stanęliśmy przed istotną decyzją: w której wersji Angulara powinniśmy go zbudować?

Właśnie została wydana werjsa beta Angulara 2 i cały Internet aż huczał od stwierdzeń, że wreszcie nadszedł właściwy czas, by poważnie brać pod uwagę budowanie produkcyjnej aplikacji w NG 2. Była to więc z pewnością kusząca opcja. Z drugiej strony, dostępny był release-candidate Angulara 1.5 (a finalna wersja 1.5.0 czaiła się tuż za rogiem), co także wydawało się ciekawą alternatywą.

Byliśmy rozdarci pomiędzy dwoma opcjami:

• Czy powinniśmy zabezpieczyć się na przyszłość, ale kosztem borykania sie z problemami wieku niemowlęcego Angulara 2?
• Czy raczej powinniśmy trzymać się dojrzałej wersji 1.5, ale kosztem zmierzenia się w przyszłości z migracją do NG 2?

Nasz wybór

Jak możesz się domyśleć patrząc na tytuł tej serii, w końcu zdecydowaliśmy się na Angulara 1.5.

By zrozumieć naszą decyzję, musimy przyjrzeć się stanowi obu frameworków, jak również sytuacji i umiejętnościom naszego zespołu oraz wymaganiom projektu.

Nasze “tło”

• W większości brak wcześniejszego doświadczenia z Angularem / nowoczesnym ekosystemem JS (dostępność dobrych materiałów edukacyjnych była więc dla nas istotnym czynnikiem).
• Start kodowania w połowie stycznia 2016 a wydanie wersji 1.0 na produkcję planowane na połowę kwietnia (nie mogliśmy sobie więc pozwolić na czekanie, by niezbędne narzędzia osiągnęły pełną dojrzałość w trakcie trwania projektu; musieliśmy mieć pewność, że wszystkie potrzebne nam technologie i zasoby są dostępne i o produkcyjnej jakości już od startu).
• Wewnętrzna aplikacja “back-office” (dostępność rozbudowanej biblioteki komponentów UI była więc dla nas istotnym czynnikiem by przyspieszyć development; oczywiście istnieje zatrzęsienie tego typu bibliotek, zależało nam jednak na czymś dobrze zintegrowanym z Angularem, żebyśmy nie musieli marnować czasu na własnoręczne pisanie dyrektyw-wrapperów dla komponentów takiej biblioteki).

Angular 2

Mimo, że oceniany jako dostatecznie stabilny do produkcyjnego użytku, w czasie kiedy podejmowaliśmy decyzję Angular 2 wciąż zawierał parę luk:

• Niekompletną dokumentację (zwłaszcza “guide” dotyczący testowania, co było dla nas poważnym minusem, jako że duzy nacisk kładziemy na TDD).
• Bardzo młody ekosystem (nieliczne “boilerplate-y” projektów, generatory yeoman-a, posty na blogach, książki, “style guide-y” itp.).
• Brak integracji z bibliotekami UI (wszyscy “główni gracze” w tym obszarze, tacy jak Angular Material, Angular UI itp. dopiero rozpoczynali migrację do NG 2 i zdecydowanie nie byli gotowi do produkcyjnego użycia).
• Niektóre obszary frameworka (np. animacje) wciąż jeszcze były nieco płynne.

W efekcie, mimo że core NG 2 faktycznie wydawał się być gotowy do produkcyjnego użycia, otaczający go ekosystem zdecydowanie nie.

Angular 1.5

Wprawdzie byliśmy niechętni, by inwestować w starzejącą się technologię, zwłaszcza w przypadku nowego projektu, jednak mimo to dostrzegaliśmy kilka mocnych argumentów za pójściem w kierunku NG 1.5:

• Umożliwia on architekturę opartą na komponentach, koncepcyjnie bardzo podobną do tej, na której bazuje Angular 2 (więcej o projektowaniu aplikacji NG 1.5 w architekturze opartej na komponentach w kolejnych postach tej serii).
• Pomimo pozornie wielkiego przeskoku koncepcyjnego, to pod maską nadal stary dobry Angular 1, integruje się więc płynnie z bogatym ekosystemem bibliotek i narzędzi NG 1.
• Core team i community Angulara wydawało się wkładać wiele wysiłku w to, by upgrade z NG 1.5 do NG 2 był tak łatwy, jak to tylko możliwe, tak więc nasza największa obawa – zablokowanie się na technologii “legacy” – była złagodzona.

Powyższe spostrzenia przeważyły szalę i w końcu zdecydowaliśmy się na Anuglara 1.5.

Spostrzeżenia po 3 miesiącach projektu

• Krzywa nauki dotycząca architektury opartej na komponentach i tego, jak testować komponenty NG 1.5 (więcej o tym jak testować komponenty w jednym z następnych postów) okazała się odrobinę bardziej stroma niż mieliśmy nadzieję. Tego typu architektura różni się znacząco od “tradycyjnej” architektury Angulara 1.4 i materiałów edukacyjnych jest niewiele (to jeden z powodów, dla których publikuję tą serię). Jednakże, sytuacja nie jest w tej chwili o wiele lepsza jeśli chodzi o NG 2, więc nie sądzę, że wybór NG 1.5 okazał się dla nas w tej kwestii utrudnieniem. Kluczową sprawą dla nas było “wyjście na zewnątrz” i uczenie się od innych opartych na komponentach frameworków, takich jak React.
• Z drugiej strony, krzywa nauki związana z Angularowymi API i róznymi detalami na poziomie implementacji okazała się znacznie bardziej płaska. Do NG 1 istnieje niemal niewyczerpana ilość wysokiej jakości materiałów edukacyjnych – nauka NG 2 byłaby o wiele trudniejsza.
• Jesteśmy niecały tydzień od naszego planowanego wydania, a ekosystem Angulara 2 wciąż nie jest dojrzały (np. nadal żadna z głównych bibliotek UI nie ma wersji pod NG 2 o produkcyjnej jakości). Tak więc, patrząc wstecz, okazało się dobrą decyzją, by nie liczyć na to, że ekosystem NG 2 osiągnie dojrzałość w trakcie trwania naszego projektu.
• Wskoczenie z pełnym impetem w architekturę opartą na komponentach okazało się właściwą decyzją. Mimo że NG 1.5 pozwala wykorzystywać komponenty w tak wąskim zakresie, w jakim tylko chcesz, pozwolenie sobie tutaj na jakiekolwiek kompromisy uczyniłoby przyszłą migrację do NG 2 o wiele trudniejszą (wymagałaby ona dużego przeskoku mentalnego i gruntownego refactoringu architektury).
• Nie zmigrowaliśmy jeszcze do Angulara 2 (wciąż jest na to trochę za wczesnie biorąc pod uwagę obecny stan ekosystemu NG 2), tak więc kierunek w którym podążamy jak również nasze założenia dotyczące tego, jak łatwa będzie migracja do NG 2 wciąż jeszcze są nie zweryfikowane. Jednak, z naszych obserwacji tego, jak rozwija się Angular 2, wygląda to obiecująco.

Wnioski

NG 1.5 to wciąż sensowna opcja dla nowej aplikacji, jednak musisz być bardzo ostrożny projektując jej architekturę. Pójdź w pełni w kierunku podejścia opartego na komponentach a wszystko powinno być w porządku (zajrzyj do pozostałych postów z tej serii jeśli chcesz dowiedzieć się, w jaki sposób my robimy to w naszym projekcie).

NG 2 może być lepszą opcją jeżeli wydanie Twojego projektu jest planowane na nieco dalszą przyszłość (czyli masz więcej czasu by czekać aż ekosystem wokół NG 2 stanie się bardziej dojrzały) lub jeśli Twój projekt jest naprawdę duży (i miałbyś w związku z tym masę kodu którą musiałbyś później zmigrować) – my najprawdopodobniej wybierzemy Angulara 2 do naszego kolejnego projektu, który planujemy rozpocząć w okolicy lipca. Jednak dla czegoś mniejszego i krótszego jest raczej trochę za wcześnie by rzucać się ślepo na NG 2 – a NG 1.5 jest całkiem dobrym przejściowym rozwiazaniem dla takiego projektu.

Co Ty o tym sądzisz?

Co myślisz o rozpoczynaniu budowy nowej aplikacji w NG 1.5 vs NG 2? Czy masz w tym obszarze jakiekolwiek praktyczne doświadczenia? Podziel się swoim zdaniem w komentarzach poniżej!