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.
- 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ń
- clojurescript ma wbudowane niemodyfikowalne typy - niesamowita sprawa w połączeniu z react
- 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)
- poza atomami jest tu dostępny styl goroutines w bibliotece async.core; chociaż w prostszych apkach bardziej mi podchodzą obietnice
- clojurescript świetnie integruje się z bibliotekami pisanymi w js, ostatnio miłem sporo frajdy piszę kod pod draftjs i rzeczami typu drag and drop
- 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
- no i REPL o którym kiedyś wspominałem, zmienia podejście do kodowania :)
- 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ę:
- 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.
- 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.
- 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ę.
- 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.
- 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.