Czemu ludzie nie lubią Angulara?

Mam trzy projekty zrobione przy użyciu różnych narzędzi:

angular2+typescript

To szybkie i agresywne, a zarazem skuteczne rozwiązanie do prowadzenia małych projektów.

Osoby, które lepiej czują się w backendzie mogą w Angularze czuć się trochę jak ryba w wodzie, ponieważ angular spina wiele znanych technik w jedno. Mowa między innymi o wstrzykiwaniu, renderowaniu szablonów, podziału kodu na klas i to wszystko sprawia, że z miejsca uzyskuje się niezłe tempo.

Angular dodatkowo jest dobry dla osób początkujących z dwóch względów:

• ma typescript, który pozwala wykryć większość prymitywnych błędów
• jako framework oferuje pewne wzorce/build blocks do budowania apki dzięki czemu w głowie rodzi się większa świadomość

Tego typu struktura chroni początkujące osoby przed nieznanym, ale owszem utrudnia pracę osobom, które dużo płynniej poruszają się w javascripcie i dynamicznym programowaniu.

Tak osobiście to średnio lubię zaglądać do kodu gdzie jest Angular, ale nie ukrywam: pomógł mi parę lat temu zrealizować jeden projekt z jakiego do dziś korzystam.

To czy w angularze będziemy się dusić zależy też wiele od typu aplikacji. Jeśli aplikacja jest bardzo dynamiczna i wymaga więcej rozbijania na mniejsze komponenty to w takim starciu jednak lepiej wypada reactjs.

javascript es6 + reactjs

Po angularze to rozwiązanie nie powiedziałbym, że było łatwiejsze, ale prostsze zrozumieniu i dostosowaniu to moich własnych potrzeb. W javascript es6 + reactjs mam postawioną kolejną własną aplikacje, gdzie pary ludzi ze sobą pracują na pewnej przestrzeni, w trakcie ich pracy content ulega różnym przekształceniom, komunikacja jest po zdarzenia na websocketach.

Ogólnie sam reactjs to tylko biblioteka od widoku i poza tym resztę trzeba jakoś wypełnić. Nie jestem javascript developerem (chociaż lubię czytać o tym języku książki), dlatego praca z redux i podobnymi rozwiązaniami to dla mnie trochę rzeźnia. Redux fajnie wygląda jak jest goły, ale jak próbujesz to wszystko spiąć razem. To jest kilka rozkmin w stylu jak obsłużyć akcje z efektami ubocznymi, jak lepiej rozkładać stan na komponenty. Wiadomo doświadczony dev ma jakieś sprawdzone po latach rozwiązaniach, natomiast to był mój pierwszy większy projekt i byłem trochę w czarnej D.

Próbowałem też przejść na inny model i użyć to co proponuje Cycle.js (ala Rx), bo jak podkreśla André Staltz w reactjs bardziej opłaca się styl funkcyjny niż imperatywny. I w sumie ma rację skoro lepiej używać propsów jako immutable. Jednak przejście na operowanie samymi strumieniami to było trochę trudne i trochę przeinżynierowane podejście.

Ostatecznie dociągnąłem bez redux i cyclejs, rozwiązanie oparłem w dużym stopniu o własne klasy zarządzające stanem i <3 eventlistener. Całość chula już z półtora roku i ani razu nie było awarii w trakcie sesji :D

clojurescript + reactjs przez rum

Mój kolejny projekt oparłem na clojurescript (z biblioteką rum). ClojureScript to lisp (inaczej mówiąc to tona tęczowych nawiasów), a mimo to w porównaniu do dwóch poprzednich środowisk jest dużo prościej.

1. rum pozwala szybciej i łatwiej tworzyć własne komponenty, wynika to trochę z uproszczonego zapisu i tego, że widoki opisuje się poprzez wyrażenia; nawet nie wiem czy to możliwe w JS, ale tutaj jako propsy przekazuje funkcje, czy inne komponenty, co znacznie ułatwia mi podział pewnych zadań
2. clojurescript ma wbudowane niemodyfikowalne typy - niesamowita sprawa w połączeniu z react
3. clojurescript oferuje narzędzia do zarządzania stanem w współbieżnym kodzie jednym z nich jest atom w którym najczęściej trzyma się stan całej apki (znika potrzeba korzystania z redux i innych protez)
4. poza atomami jest tu dostępny styl goroutines w bibliotece async.core; chociaż w prostszych apkach bardziej mi podchodzą obietnice
5. clojurescript świetnie integruje się z bibliotekami pisanymi w js, ostatnio miłem sporo frajdy piszę kod pod draftjs i rzeczami typu drag and drop
6. są dodatkowe narzędzie, które dają lepszy feedback ze strony kodu np. hotreloading (figwheel) fajna rzecz gdy chcesz podtrzymać stan w apce bez odświeżania projekty, by zaraz później ujrzeć zmiany jakie wywołał kod na twoim stanie
7. no i REPL o którym kiedyś wspominałem, zmienia podejście do kodowania :)
8. kończąc projekt widzę największą różnicę, wcześniej pewna znacząca część kodu odpowiadała za strukturę aplikacji, ale sama w sobie nie była logiką; a teraz prawie cały kod jaki mam to żywe mięso zero zbędnych abstrakcji, dla mnie to szok :D

EDIT:

Wymieniłem same plusy, a nic nie wspomniałem o minusach, a ich też jest trochę:

1. Czasem przez niektóre wbudowane i podstawowe makra idzie dostać błąd który nic nie mówi. Jedynie wiadomo w którym pliku to się stało. Np. jak oznaczę, że wybrana nazwa jest funkcją a przypisze jej wartość jak do zmiennej to leżę. Wtedy mniej więcej na 5-10 min znikam a mój czas idzie do piachu.
2. Trzeba mieć trochę doświadczenia z javascript. Niektóre błędy są na pograniczu js a clojurescript i wtedy przydaje się zarazem wiedza z javascript jak i clojure.
3. Standardowa biblioteka w clojurescript dla wielu operacji zwraca nieszczęsne leniwe sekwencje. One są problematyczne jeśli wpuści sie ję do asynchroniczniego kodu, łatwo wtedy idzie zgubić kontekst wykonania i pojawiają się trudniejsze do wyłapania błędy. Dlatego przed opuszczeniem funkcji pilnuje, by zmarterializować sekwencję.
4. Atomy są OK, ale trzeba mieć kilka dobrych pomysłów, aby napisać apkę podzieloną na moduły, która jest zależna od jednego atomu. To jest chyba najtrudniejszy element po którym pisanie apki idzie z góry.
5. To nie jest tak, że clojurescript sam pisze Ci aplikacje i masz efekt wow. Ogólnie to jest tak, że jak nie dbasz o przestrzenie nazw, odpowiednie warstwy, składnie funkcji, układanie przepływu w funkcjach, podział funkcji na side effect i obliczenia to język sam Ciebie zjada, na wielu rzeczach się przejechałem nim zrozumiałem od której strony należy je podejść. No i w rezultacie refaktoring to chyba najmniej przyjemna rzecz.

@mr_jaro:

vue nie lubię za dużo nerwów mnie kosztował i te rąbnięte mieszanie css, js i html w jednym pliku, pfu, a gdy popatrzyłem na reacta to tak samo by mnie wk*****ł więc wole nie ruszać

?

masz dwa pliki:

• plik vue z "code behind" (obliczanie/zaciąganie/mielenie)

• oraz vue html z samymi v ifami, v loopami itd.

css masz osobno i oczywiście wszystko przerobione na componenty.

gdzie tu mieszanie? przecież to są same bindy do jakichś property lub innych computed things.

@WeiXiao: może coś się zmieniło ale to musiało ostatnio, bo jeszcze rok temu twórcy się zapierali, że wsadzanie wszystkich 3 rzeczy do jednego pliku to najlepsze rozwiązanie i nie dodadzą wsparcia do dzielenia tego na pliki. Dało się dzielić zewnętrznymi dodatkami które twórcy uznawali za złe dlatego nikt tego nie robił.

Edit o tym mówie, to było jedyne rozwiązanie przez długi czas na komponenty https://vuejs.org/v2/guide/single-file-components.html

Jeszcze dochodzi domyślny framework do testowania: Jasmine... wieczne problemy z nim były bo do działania musi mieć przeglądarkę (nawet do testów jednostkowych), ciągłe problemy przez to z CI/CD bo a to testy nie przechodziły, a to headless browser się wywalał, same testy przez to trwały dłużej... może teraz się polepszył ale dla mnie ten jasmine w porównaniu do jest słabo wypadał.

Znam osoby którym się podobał angular ale one nigdy nie testowały swoich aplikacji, nie implementowały CI/CD, a same aplikacje które pisali były dość proste.

W Angularze jest też trudniej re-używać komponentów. Ogólnie kodu jest więcej a wynik taki sam jak nie gorszy. Lubię za to nestjs który jest takim "expressowym angularem" dla backendu (twórcom chyba przypadł do gustu angular). Ale to inna para kaloszy.

I ta biedna dokumentacja, niekompletna a w niektórych miejscach nieaktualna.

Generalnie to się zgadzam z wszystkimi uwagami powyżej.

Czyli widzę, że 90% ludzi na forum woli Reacta.

Angulara już znam, teraz powiedzcie co takiego lepszego react może mi zaoferować, czym moglibyście mnie zachęcić do poznania reacta,
To, że to jest biblioteka a nie framework i idzie z wadami i korzyściami biblioteki. Będziesz mógł dowolnie sobie skonfigurować cały setup lub zostawić tylko renderowanie komponentów.

@MuadibAtrides psssst angulara też tak się da

ja wole Angulara (nie znaczy że Reacta nie trawię) bo w bibliotece od facebooka wkurza mnie:

• JSX, ciężko się mi w tym było ogarnąć przy większych templatach z wieloma warunkami
• deklaratywny styl, chociażby definowanie route'ów w JSX jakieś takie dziwne
• co już zostało wcześniej wspomniane, właściwie kompletna dowolność w implementacji i strukturze apki, co może być zaletą ale póki co ja trafiałem na projekty gdzie wszystko było totalnie pogmatwane na różne sposoby

nobody01 napisał(a):

@Wibowit: ? Hejt dotyczy Angulara, a to chyba Reacta się porównuje do PHP.

Niektórzy porównują Reacta do PHP patrząc powierzchownie na JSX vs PHP jako template language, ale poza tym pozornym podobieństwem to niewiele mają wspólnego.
Jak spojrzysz na sam paradygmat i używane techniki to Angularowi dużo bliżej do PHPowych frameworków - nacisk na OOP, kontener DI, serwisy itp.

Brak jakiś konkretnych argumentów przekonujących mnie do choćby spróbowania reacta, sama aplikacja angularowa może jest kobyłą, ale to tylko jednokrotny problem przy tworzeniu projektu, trochę pakietów musi zaciągnąć z sieci. Potem sama praca w angularze to przyjemność,

Veox napisał(a):

• JSX, ciężko się mi w tym było ogarnąć przy większych templatach z wieloma warunkami

w angularze sam html od logiki sensownie rozdzielony.

Veox napisał(a):

• deklaratywny styl, chociażby definowanie route'ów w JSX jakieś takie dziwne

routing w angularze jest bajecznie prosty.

I wiele innych rzeczy można by tu przytoczyć.