W mojej karierze programisty nastąpił moment kiedy z pracy nad poważnym backendowym kodem w typowym dla dojrzałych firm języku jakim jest C# zostałem wrzucony w świat, o którym Wam teraz coś powiem. W świat aplikacji angularowych.

Jest to smutna opowieść o tym jak absurdalnym i nieodpowiedzialnym jest chęć użycia Angulara w Twojej firmie.

Absolutnie NIE używaj Angulara ponieważ…

1. wymaga nauki bardzo wielu zupełnie innych narzędzi

Praca w C# pozwala Ci korzysta z jednego, dobrze znanego i rozbudowanego narzędzia jakim jest Visual Studio. Wchodzisz rano do biura, włączasz jeden program i świat stoi przed Tobą otworem. Wszystko na miejscu. Wszystko poukładane. Jedno okno by rządzić wszystkim. Nie ma nic wygodniejszego niż zintegrowane środowisko dające Ci dostęp do wszystkich niezbędnych narzędzi. Kilkoma kliknięciami jesteś w stanie użyć kolejnych szablonów dla plików i projektów. A jak brakuje szablonu to w tym samym miejscu szukasz kolejnych. Kilka kliknięć i aplikacja działa. Nie istnieje wygodniejszy sposób budowania gigantycznych projektów generujących milionowe dochody dla Twojej dojrzałej, dominującej na rynku firmy.

Nie było więcej?

Próbujesz dotknąć Angulara i okazuje się, że wymyślał to chyba jakiś dzieciak, który nigdy nawet na etacie nie pracował! Każą Ci instalować osobno manager bibliotek, osobno edytor, osobno narzędzia do generowania kodu! W dodatku każde z nich upośledzone, robiące tylko jedną rzecz.

Poza edytorem wszystko musisz pisać w konsoli. Jak jakiś podrzędny admin, dla którego nikt nawet porządnych okienek nie zrobił i musi pamiętać wszystkie komendy systemu żeby w ogóle utworzyć plik. Niepoważne. Nic nie da się ustawić pod siebie. Praktycznie zero konfiguracji! A jeśli już coś da się zmienić to okazuje się, że możesz to zrobić tylko grzebiąc w setkach osobnych plików na dysku.

Edit

No i te edytory! Myślałeś, że pisanie w notatniku odeszło w niepamięć już w latach 90 kiedy ostatni uczniowie robili swoje głupie stronki na lekcjach informatyki? Nic bardziej mylnego. Musząc pracować z Angularem będziesz zmuszony wrócić do tych czasów. Kiedy zapytasz osoby pracujące z Angularem jaki IDE polecają to one Ci podsyłają nazwy jakichś edytorów tekstu  z dodanym drzewkiem folderów. A Ty pytałeś jasno o IDE. Widocznie nikt nie wpadł na to, żeby zrobić narzędzie chociaż trochę zbliżone do poważnych i szanowanych rozwiązań liderów rynku.

Zawsze i wszędzie

Mówią, że to pozwala pracować na wielu systemach operacyjnych. Świetnie. Tylko kto poważny używa czegoś innego niż Windows? Że niby można dobrać zestaw narzędzi pod siebie? Super. A czy jak kupujesz meble to osobno wybierasz każdą śrubkę czy jednak liczysz, że cały zestaw zaprojektuje za Ciebie ktoś kompetentny pracujący u producenta? Jedno, zaprojektowane przez poważne osoby, środowisko gwarantuje Ci, że jest to narzędzie przemyślane i optymalne. Dostajesz gotowe stanowisko pracy. Takie samo jak inni w firmie więc kiedy idziesz o coś zapytać kolegę to nie tracisz czasu na szukanie gdzie na jego ekranie jest okno z kodem. Macie to samo IDE więc niezależnie od sytuacji wszystko jest na swoim miejscu.

Jednak środowisko Angularowców, do którego z przymusu próbujesz wejść, chce Ci wmówić, że masz sobie sam składać wszystko tak jak Ci wygodnie. Ale skąd masz wiedzieć co będzie wygodne? Nie jesteś ekspertem od UX. Stracisz tygodnie na walce z narzędziami i instalowaniem dziesiątek malutkich programików, które różnią się ułożeniem przycisków i ilością opcji w menu, zamiast dostać wszystko od razu i po prostu pracować.

2. Angular wymaga przerobienia całego backendu

W poważnym projekcie, w którym pracujesz, cała logika i wszystko co istotne znajduje się w backendzie. W jednym miejscu. Nie ma potrzeby tego nikomu udostępniać. Macie kontrolę nad tym gdzie są wszystkie informacje i procesy. Widoki to tylko efekt uboczny. Z resztą tylko wyświetlają to co im Wasz porządny backendowy kod da i są z nim mocno związane. Dzięki tej więzi wszystko jest spójne i stabilne. Wszystko działa szybko bo przecież widok to tylko kontener na dane. Serwer wszystkim się zajmuje i na pewno jest dużo szybszy od komputera użytkownika.

Jedno zapytanie do Waszej aplikacji i od razu wszystkie potrzebne dane są widoczne dla użytkownika na obszernej stronie. Dzięki temu nic mu nie umknie. Dodatkowo macie kontrolę nad tym jak te dane są prezentowane. Nikt nie będzie Wam rzucał głupich pomysłów typu udostępnienie danych klientowi bez całego widoku. Po co komu te dane skoro nie wie jak mają być pokazane?! Ty to wiesz więc to Ty masz kontrolę nad tym jak je pokażesz. Klient dostaje to w konkretnej formie. Dzięki temu nie będzie się skarżył, że coś jest nie tak.

Niewiadoma

Aż tu nagle ktoś wpadł na pomysł wepchnięcia Angulara. Masakra. Mówią, że serwer ma tylko zwracać gołe dane i je przyjmować. Nie wiadomo jak te dane są potem prezentowane. A jak już ubrudzisz się w Angularze to będziesz z drugiej strony – coś wyświetlasz, ale nie wiesz skąd to się bierze. Bezsens. Jak w takim trybie pracy być ekspertem w dziedzinie i znać cały proces biznesowy.

Gdzie tu prostota?

Musisz się łączyć z backendem, robić kilka zapytać. Narzut gigantyczny. Twoje widoki połączone z backendem działały błyskawicznie i od razu dawały wszystko. A to? To jakiś żart. Jak można nie mieć kontroli nad tym jak są przetwarzane dane, które się wyświetla? I w drugą stronę. Serwer przyjmuje dane, ale nie ma konkretnego formularza, który mu te dane przysyła. W swoich porządnych aplikacjach jak coś się źle zapisywało to mogłeś otworzyć konkretną stronę z konkretnym formularzem i debugować całą ścieżkę. A teraz dostajesz jakieś dane, ale nawet nie wiesz kto je wysłał. I to ma być prostota?

Robi się niebezpiecznie

A już nie daj boże ktoś powie, że nie można zapisywać stanu poprzedniego requestu tak żeby z niego skorzystać przy następnym requeście. Przecież po to serwery mają tyle pamięci RAM, żeby takie rzeczy pamiętać. Jak robisz formularz, który ma kilka kroków to każdy krok ma nie wiedzieć o poprzednim? Powaliło ich. Albo kompletną porażką jest nie zapisywanie sesji użytkownika. Że niby on sam nam powie, że on to on za każdym razem. A jak Ty to niby sprawdzisz? Uwierzysz mu? Haha! Sesja na serwerze jest po to, żeby wszystko było proste, spójne i bezpieczne. Kropka.

3. będziesz pisał logikę w widokach

Postawmy sprawę jasno – widok ma wyświetlać dane. To do czego użytkownik ma dostęp nie może być za nic odpowiedzialne. W końcu wiadomo, że ten użytkownik będzie chciał wszystko zepsuć. Poza tym wszystko powinno być w jednym miejscu, którym zarządzają najbardziej doświadczeni programiści. Kiedy ktoś Cię pyta jak coś działa to masz konkretne 5 folderów, opisanych odpowiednimi nazwami, w których znajdziesz wszystkie reguły.

Gdzie sens, gdzie logika…

A teraz nagle ktoś Ci mówi, żebyś część logiki pisał w Angularze. No kurde, czy oni są poważni? Logika w kodzie, do którego ma dostęp użytkownik? Przecież to upadnie pierwszego dnia. Nikt poważny nie robi takich rzeczy. Do tego musisz utrzymywać logikę w dwóch miejscach. Weź teraz znajdź coś… Że niby widoki mogą czasami działać bez połączenia z serwerem? Hahaha, niby jak? Nie przyszło z serwera lub nie doszło do serwera to nie istnieje i nie ma sensu. Nie wolno liczyć niczego po stronie użytkownika. A tutaj nagle ktoś twierdzi, że można jakieś sumy robić na widokach? Walidacja danych po stronie widoków? Głupota i krótkowzroczność. I tak potem to trzeba jeszcze raz wszystko sprawdzać. Więc nie dość, że głupota to jeszcze marnująca czas, a przez to pieniądze firmy.

4. nie będziesz mógł korzystać ze sprawdzonych protokołów komunikacji

Wszystkie największe instytucje korzystają ze sprawdzonych i dobrze znanych sposobów komunikacji takimi jak WSDL pomiędzy swoimi kluczowymi produktami. Od lat to działa. Wspierają to poważne firmy jak Microsoft. Większość dokumentów w Twojej firmie zakłada, że korzystasz z tych rozwiązań. Wszyscy wiedzą do czego służą i jak wygląda ich używanie. Wszystko jest bezpieczne, dobrze zdefiniowane i sprawdzone.

Zero wygody

I nagle poznając Angulara widzisz, że każą Ci zrezygnować z tych idealnych rozwiązań i robić wszystko bez żadnych kontraktów pomiędzy usługami czy autoryzacji na poziomie Windowsa. Do tego nie wiesz jakie dane przychodzą. Jakie dane wysłać? Musisz szukać w dokumentacjach, rozmawiać z innymi pracownikami. No i bezpieczeństwo. Mówią Ci, że będziecie dawać dostęp użytkownikom tylko dlatego, że na ich komputerach jest jakiś kawałek tekstu zapisany w przeglądarce dawno temu. Jak coś co nie wymaga za każdym razem sprawdzania czy użytkownik istnieje w bazie i systemie ma być bezpieczne?! Przecież zaraz ktoś to wykradnie i firma będzie miała problemy. W dodatku musisz przyjąć myśl, że można zaufać użytkownikowi. A przecież wiadomo, że użytkownik albo jest głupi albo chce zniszczyć Twój biznes.

5. co chwilę będziesz przepisywał projekt od początku

Raz napisana aplikacja działa stabilnie przez wiele lat. Skorzystałeś ze stabilnych wersji bibliotek, których używasz od lat. Wszyscy je znają, nikomu nie trzeba tłumaczyć czemu coś działa w taki, a nie inny sposób. Wygodne i bezpieczne. Najważniejszą sprawą w firmie jest STABILNOŚĆ. A stabilne są tylko rozwiązania sprawdzone, które znasz na wylot.

Korporacyjne standardy są po to żeby ułatwić wam pracę. Skoro ktoś wybrał kiedyś takie rozwiązanie to znaczy, że miał poważny powód. Wiedział co robi i nie można podważać jego kompetencji. Jakakolwiek zmiana to nie tylko ryzyko zachwiania stabilności, ale też koszty! A firma ma zarabiać. Nie może pozwolić sobie na koszty. Jeśli ludzie pracują w projekcie, który ma ugruntowaną strukturę to czują się w nim pewnie. Są zadowoleni, że nie rzuca się im kłód pod nogi. Ty jesteś taką osobą. Cenisz sobie spokój i dziękujesz firmie, że pozwala Ci pracować w stabilnym środowisku. W takim, w którym możesz być pewny tego w którą stronę idziesz i co będzie jutro. W końcu jesteś poważną, dojrzałą osobą, która wymaga stabilności w życiu.

Chaos

Jednak Angularowcy tego nie chcą. Wolą żyć w chaosie. Nic nie jest stabilne, wszystko się zmienia. To, że dzisiaj piszesz w jednym narzędziu nie znaczy, że jutro będziesz je mógł nadal używać. Bo nagle stanie się niekompatybilne. Właściwie co miesiąc trzeba sprawdzać czy nie było jakiejś aktualizacji. Że nie pojawiła się nowa biblioteka, która podchodzi do problemu inaczej. Obłęd.

Nie potrafią zrobić jednego rozwiązania, które będzie działać latami. Co chwilę nowe standardy, nowe praktyki. Bezsens. Jak coś może być poważne jeżeli szanowana korporacja nie może tego bez problemu i ciśnienia na zmiany sprawdzić w ciągu kilku lat? Ale Angularowcy będą Ci mówić, że tak jest ok. Że trzeba podążać za trendami bo klienci tego chcą. Gówno prawda.

Sprawdzone rozwiązania to klucz sukcesu

Wasi klienci od 10 lat używają Waszych desktopowych narzędzi i aplikacji webowych, które mają surowy, wyglądający profesjonalnie i poważnie wygląd. Nikt nie chce zmian. W końcu nikt nie przyszedł ostatnio i nie powiedział, że to narzędzie mu nie pasuje. Więc o co tym gościom chodzi? Tracą pieniądze pracodawcy wprowadzając nowości, których nikt nie chce. W dodatku zamykają się na sprawdzone, używane w poważnych podmiotach narzędzia pracy takie jak przeglądarka Internet Explorer. Gdyby nie była dobra to dlaczego tyle firm by z tego korzystało? A oni twierdzą, że wsparcie dla stabilnych wersji 8 czy 9, które są proste i znane każdemu to bezsens. Bezsensem jest ich pogoń za dopiero co wymyślonymi zabawkami dla dzieci takimi jak HTML5 czy ECMA Script 6.

Podsumowując

Absolutnie nie zgadzaj się robić czegokolwiek w Angularze! Jeżeli cenisz sobie stabilność i sprawdzone rozwiązania to nie dotykaj tego tworu. Jeśli jesteś dojrzałym człowiekiem, który nie ma zamiaru się uczyć się czegoś nowego nie idź w tym kierunku. Jeśli interesuje Cię wygodna posada i brak konieczności rozwiązywania nowych problemów to zostaw ten świat dzieciakom, którzy ciągle by się czegoś uczyli, coś zmieniali, biegli naprzód. Niepoważny produkt dla niepoważnych ludzi. Ciągłe zmiany. Ciągłe poprawianie kodu. Ciągle nowe narzędzia. To jest chore. Nie jest to praca dla tak poważnych ludzi jak Ty. Nowe standardy, które nie mają ugruntowanej na rynku i popartej latami testów renomy. Chwilowa moda.

Jeśli zaś tak jak ja jesteś niepoważnym człowiekiem i chcesz poświęcać cenny czas na naukę nieistotnych głupot to zapraszam na stronę https://angular.io/tutorial. Skoro taki sceptycznie nastawiony do pracy z frontendem człowiek jak ja skończył jako frontend developer to i Ty dasz radę. A potem podzielisz się w komentarzach tym jaki sukces odniosłeś.