Moje przemyślenia po roku z Angularem

Jak trafiłem na Angulara?

Web developmentem zainteresowałem się w okolicach 2017 roku, kiedy to postanowiłem zmienić dotychczasową ścieżkę kariery zawodowej. Początkowo, z racji posiadanych umiejętności obsługi programów graficznych, planowałem zająć się tworzeniem stron internetowych. Szybko okazało się jednak, że technologie frontendowe pozwalają na wiele więcej niż tworzenie statycznych stron wizytówek. W ten sposób trafiłem na kurs React'a na platformie Udemy, dzięki któremu poznałem podstawy budowania aplikacji webowych. Wybór ten był dość naturalny. Już wtedy React cieszył się największą popularnością spośród frameworków frontendowych, a ilość dostępnych w sieci materiałów do nauki była nieporównywalna. Dodatkowo największy rywal - Angular, nie miał dobrej prasy i był raczej odradzany dla początkujących z uwagi na wyższy próg wejścia. Tkwiąc w reactowej bańce, podświadomie budowałem w sobie uprzedzenie do Angulara i przeświadczenie, że to framework toporny i nienadążający za zmianami w dynamicznym świecie frontendu.

Po pewnym czasie znalazłem pracę w agencji marketingowej. Najpierw jednej, później w kolejnej. Tam do czynienia miałem głównie z Wordpressem. Nie był to wymarzony start, ale przynajmniej mały krok naprzód w drodze do celu. W międzyczasie tworzyłem projekty do portfolio oparte o React i to z kolei pozwoliło na dużo większy krok naprzód. Trafiłem na bootcamp do dużej korporacji, gdzie okazało się, że frontend aplikacji, którą będziemy budować w ramach nauki będzie oparty o Vue. Pierwsze wrażenia związane z pracą z tym fremeworkiem były jak najbardziej pozytywne. Po dłuższym czasie spędzonym z Reactem, nauka Vue była bardzo przyjemna. Dało się odczuć, że jest to framework, który powstał w oparciu o doświadczenie z innych narzędzi jak React czy Angular i dzięki temu Developer Experience jest na wysokim poziomie.

Po ukończonym bootcampie przyszła kolej na pierwszy projekt komercyjny z prawdziwego zdarzenia. Po cichu liczyłem, że będę mógł kontynuować przygodę z Vue lub wrócę do macierzy i trafię do projektu, gdzie wykorzystywany jest całkiem dobrze już mi znany React. Tutaj jednak warto przywołać słowa Woodiego Allena - jeśli chcesz rozśmieszyć Boga, powiedz mu o swoich planach.

Pierwszy projekt komercyjny

Jak się można domyślać, w moim pierwszym projekcie z prawdziwego zdarzenia los zesłał na mnie Angulara. Dołączyłem, w roli frontend developera, do międzynarodowego zespołu odpowiedzialnego za jeden z modułów dużej aplikacji typu enterprise służącej do zarządzania projektami jednej z instytucji Unii Europejskiej. Stack technologiczny w tym przypadku to Angular i Spring Boot(Java) czyli dość popularne połączenie w przypadku tego typu systemów.

Przez dłuższy czas przebywałem w reactowej bańce informacyjnej, co sprawiło, że nie byłem zachwycony koniecznością nauki Angulara. Naczytałem się wielu niepochlebnych opinii na temat frameworka od Google. Nie pozostało jednak nic innego jak zacisnąć zęby i przystąpić do przyspieszonego kursu trzeciej już technologii frontendowej w mojej krótkiej karierze programisty. W końcu to tylko narzędzie, a koncepty leżące u podstaw frameworków pozostają niezmienne. Pierwszy kontakt był taki, jaki można było się spodziewać. Byłem przerażony, kiedy po raz pierwszy zobaczyłem angularowy kod, który bardziej niż framework frontendowy przypomniał aplikację napisaną w Javie. Po programowaniu funkcyjnym i hookach, klasy i dekoratory wyglądały co najmniej egzotycznie. Jak widać pierwsze wrażenie nie było najlepsze. Co było dalej?

Hard to learn, hard to master?

Według obiegowej opinii początkujący adepci sztuki frontendowej raczej powinni unikać Angulara jako swojego pierwszego frameworka i... ciężko się z tym nie zgodzić. Zagadnień, które trzeba przyswoić na początku jest naprawdę sporo. Jakiś czas temu poświęciłem nawet osobny wpis temu, co warto wiedzieć na początku. Możesz go znaleźć tutaj. Najbardziej jednak próg wejścia do Angulara podnoszą takie zagadnienia jak modularność(a komu to potrzebne?) i sławetny RxJS. A kiedy dodamy do tego zarządzanie stanem z NgRx, otrzymujemy gotową mieszankę na przegrzanie neuronów. Dlatego też muszę przyznać, że stawianie pierwszych kroków było po prostu trudne i wymagało nadprogramowej determinacji. Szczególnie, że przecież dopiero co uczyłem się Vue, który wydaje się znacznie przystępniejszym narzędziem. W procesie nauki nieocenione okazały się code review i możliwość podejrzenia kodu napisanego przez bardziej doświadczonych developerów.

Pomimo, że Angular, porównując go do innych frameworków, prawdopodobnie wymaga więcej poświęconego czasu, by przyswoić podstawy to już czas potrzebny, by pisać dobrej jakości kod w moim odczuciu jest podobny, a może nawet i ktrótszy niż w przypadku innych frameworków.

Co polubiłem w Angularze?

Mógłbym tu rozpisywać się o tym, że Angular to kompletny framework z prawdziwego zdarzenia, gdzie nie musimy przejmować się wyborem biblioteki do obsługi routingu czy formularzy, bo wszelkie potrzebne narzędzia otrzymujemy out of the box, ale to raczej nic odkrywczego. Dlatego chciałbym tu skupić się bardziej na moim subiektywnym developer experience.

RxJS

Biblioteka RxJS, podobnie jak Typescript, na stałe wpisana jest w krajobraz Angulara i to między innymi przez obsługę strumieni reaktywnych pierwsze kroki w angularze nie należą do najprostszych. Kiedy jednak przebrniemy przez podstawy i zaczniemy zgrabniej poruszać się w środowisku RxJS, łącząc ze sobą strumienie i przekształcać dane za pomocą licznych operatorów, okaże się, że przynosi to masę satysfakcji. Na jednym końcu mamy strumień emitujący jakieś dane, a na drugim finalny kształt w jaki te dane mają zostać przekształcone. Zadanie polega na tym by za pomocą różnorakich struktur i operatorów(a jest ich naprawdę sporo) stworzyć optymalne rozwiązanie. Tego typu mini-zagadek logicznych w pracy ze strumieniami jest naprawdę sporo i muszę przyznać, że od strony programistycznej jest to świetna zabawa. Poza przekształcaniem skomplikowanych struktur danych, RxJS umożliwia także zwracanie wielu wartości jednocześnie czy też łatwe anulowanie subskrybcji.

Programowanie deklaratywne

Ten punkt poniekąd wiąże się z poprzednim. Angular w parze z RxJS to potężny duet, który pozwala na tworzenie reaktywnych interfejsów za pomocą w pełni deklaratywnego kodu, co mimo, że na pierwszy rzut oka wydaje się trudniejsze, pozwala uniknąć bałaganu i trudnych do zlokalizowania błędów.

Reaktywne formularze

Reactive forms to połączenie formularzy i strumieni reaktywnych i muszę przyznać, że RxJS sprawdza się w tym przypadku świetnie. Reaktywne formularze pozwalają wygodnie tworzyć inputy i dowolnie łączyć je w grupy organizując dane wprowadzane przez użytkownika w postać strumieni.

TypeScript by default

Mimo, że TypeScript przeżywa ostatnio gorsze chwile, osobiście nie wyobrażam sobie bardziej złożonego projektu bez statycznego typowania, które pomaga zarówno w utrzymywaniu kodu, jak i jest wprost bezcenne przy wdrożeniu do nowego projektu. Angular postawił na TS już od samego początku i wydaje się to połączeniem nierozerwalnym.

Co mnie irytuje?

Jak każde narzędzie, Angular posiada również pewne mniej lub bardziej irytujące wady, które skutecznie potrafią obniżyć Developer Experience.

RxJS spaghetti

Tak, RxJS to potężne narzędzie, które pozwala budować w pełni reaktywne aplikacje i świetnie sprawdza się przy pracy ze złożonymi strumieniami danych jak interakcje użytkownika, formularze czy komunikacja z WebSocketami. Jego potężna moc to jednak miecz obusieczny. Złożoność sprawia, że łatwo możemy wpaść w pułapkę tworzenia nad wyraz skomplikowanych, trudnych do utrzymania konstrukcji. Mniej wprawieni programiści łatwo mogą pokusić się o anty-wzorzec w postaci np. zagnieżdżonych subskrybcji. Łatwo także o trudne do zlokalizowania błędy typu race condition związane z kolejnością emitowania danych przez różne strumienie.

Kolejną kwestią jest nadużywanie RxJS i stosowanie go w miejsach, gdzie lepiej sprawdzą się obietnice. Mowa tu np. o prostych, pojedynczych żądaniach HTTP, gdzie otrzymujemy pojedynczą wartość, której nie musimy przekształcać w złożony sposób. Inaczej ma się sytuacja, gdy pewne żądania chcemy wysyłać wielokrotnie, jak ma się to na przykład w przypadku paginacji lub automatycznego ponawiania żądania w przypadku błędu. Więcej na ten temat tutaj.

Moduły

Kto, pracując z Angularem, nie przechodził ciężkich chwil zmagając z konfiguracją modułów niech pierwszy rzuci kamieniem. Decyzje o tym co powinno zostać zaimportowane do modułu, co wyeksportowane i jak skonfigurować providery serwisów potrafią przyprawić o ból głowy. Co prawda zespół Angulara, wdrażając standalone components, poczynił znaczące kroki w umożliwieniu nam pozbycia się modułów lub przynajmniej uszczuplenia wpspółdzielonego modułu z masą komponentów. Jednak w przypadku dużych aplikacji migracja może okazać się bolesna, a całkowite pozbycie się modułów często niemożliwe. Jestem zdania, że efektywny tree shaking i optymalizacja wielkości kodu końcowego to coś, co w nowoczesnym frameworku powinno odbywać się pod maską.

Testowanie

Niegdyś uważałem, że pisanie testów jednostkowych to jedna z przyjemniejszych części tworzenia aplikacji. I wtedy musiałem napisać swój pierwszy test w Angularze... O ile rozpoczęcie zabawy z testami w React czy Vue było bardzo przyjemne, o tyle to w przypadku Angulara nie jest już tak kolorowo i próg wejścia do testowania jest naprawdę relatywnie wysoki i nie mówię tu wyłącznie o moich doświadczeniach. Koledzy po fachu, z którymi mam okazję pracować są podobnego zdania.

Quo Vadis Angular?

Angular przez długi czas miał łatkę przestarzałego frameworka który nie nadąża za dynamicznie zmieniającym się światem web developmentu. Ostatnimi jednak czasy tempo jego rozwoju znacząco wzrosło i w ostatnich wydaniach nie brakowało rewolucyjnych zmian jak wspomniane już przeze mnie standalone components czy też zapożyczone z Solid.js signals, które przybliżają Angulara do Reacta, Vue czy Svelte. I choć wydawać by się mogło, że jest to jednoznacznie dobry kierunek rozwoju, nie brakuje w sieci głosów niezadowolenia mówiących, że Angular starając się „dogonić” resztę stawki, traci swoje główne atuty. Jednym z nich jest stabilność i fakt, że Angular uchodził za narzędzie rozwijane stopniowo, nie zważające na to, w którym kierunku podąża reszta. Trzeba mieć na uwadze, że angular, z uwagi na swój obiektowy charakter, jest najchętniej wybieranym frameworkiem przez programistów Javy decydujących się na mezalians z frontendem i to zapewne ta grupa stanowi duży procent nieprzychylnych głosów.

Zespół Angulara najwyraźniej postanowił jednak powalczyć o uwagę nowych programistów i lepsze noty w ankiecie State of JavaScript. Co by nie mówić, rozwój w świecie frontendu jest konieczny, by utrzymać się na powierzchni, więc z ciekawością będę wypatrywał nowych wersji.

Czy warto uczyć się Angulara w 2023 roku?

Najpierw warto sobie zadać pytanie czym jest Angular i w jakiego typu projektach jest zazwyczaj wykorzystywany. Angular jest frameworkiem do tworzenia interaktywnych aplikacji webowych i najlepiej sprawdzi się przy tworzeniu tzw. SPA - Single Page Applications, gdzie niekoniecznie zależy nam na dobrym SEO i SSR. Z uwagi na swoją stabilność i fakt, że za Angularem stoi duży gracz jakim jest Google, często wykorzystywany jest, wraz z Javą, do budowania dużych, skalowalnych aplikacji enterprise. I to właśnie głównie w tego typu projektach będziesz uczestniczył wybierając tę ścieżkę. Na pytanie czy warto wejść do świata Angulara każdy już musi odpowiedzieć sobie sam. Nadal masa dużych aplikacji oparta jest o ten framework i jeszcze przez długi czas ktoś będzie musiał je rozwijać i utrzymywać, a zespół pracujący nad rozwojem Angulara udowodnił ostatnimi zmianami, że nie ma zamiaru, by ten stał się jedynie legacy frameworkiem wolno snującym się za konkurencją. Ponadto znajomość Angulara może pomóc wyróżnić się na rynku nasyconym programistami React. Jak można zobaczyć na poniższej grafice, wykorzystanie Angulara cały czas stoi na wysokim poziomie, więc ofert pracy nie brakuje i choć jest ich znacząco mniej niż w przypadku Reacta, konkurencja również jest mniejsza.

Podsumowanie

Pierwszy rok pracy w projekcie komercyjnym, poza masą nowej wiedzy stricte technicznej i nauką funkcjonowania w zespole deweloperskim, przyniósł także kilka refleksji. Przede wszystkim wyzbyłem się sentymentów do frameworków i bibliotek. Oczywiście z jednymi pracuje mi się lepiej i wygodniej niż z innymi, ale w gruncie rzeczy to tylko narzędzia, które w jednych projektach sprawdzą się lepiej, a w innych gorzej, a social mediowe przepychanki pomiędzy fanami poszczególnych rozwiązań powinniśmy traktować z dużym przymrużeniem oka. Dodatkowo poznanie kilku różnych narzędzi pozwoli mieć szerszą perspektywę i w przyszłości odpowiednio dobrać stack przy tworzeniu własnych lub klienckich projektów.

A Ty jakie masz doświadczenia z Angularem? Jakie dostrzegasz zalety i wady frameworka od Google? Podziel się swoją opinią w sekcji komentarzy.

Bądź ze mną w kontakcie na Twitterze lub LinkedIn, jeśli interesuje Cię świat aplikacji webowych 😉