Angular - jak sie z tym pracuje

Odpowiedz Nowy wątek
2015-02-07 16:31
0

Bylem dzisiaj na prezentacji odnosnie Angulara, ktora bardzo mi sie spodobala. Pytanei cyz w rzeczywistosci praca z nim tez jest latwa prosta i przyjemna?

Pozostało 580 znaków

2015-02-07 16:45
2

Łatwa i przyjemna na początku i przy bardzo małych projektach. Angular ostatnio otrzymuje dużo krytyki i to konstruktywnej. Odnoszę wrażenie, że emocje powoli opadają, szczególnie u tych, którzy zaczynali jak framework zyskiwał popularność i teraz są po 2 latach pracy w nim. Nie chcę cię zniechęcać - wręcz przeciwnie - lubię Angulara, ale jakbym miał tworzyć własny produkt i go utrzymywać, to wziąłbym coś innego. Ma swoje mocne strony, ale za dużo jest tych słabych. Jak chcesz usłyszeć jakieś konkrety, to pytaj.

Pozostało 580 znaków

2015-02-07 17:22
3

I wszystkich …uj strzeli jak wyjdzie Angular 2.0, który z poprzednim będzie miał wiele wspólnego: nazwę.

A tak bardziej serio to ostatnimi czasy znacznie bardziej jest popularny Flux od FB. Głównie z racji tego, że:

Facebook stworzył Reacta i go używa. Google przejęło Angulara i go nie używa.

I test to brutalna prawda. Google Angulara użyło tylko w YT dla PS3. Dodatkowo wiele osób uważa, że to jest taki framework korpo dla JSa.

Pozostało 580 znaków

2015-02-07 17:27
0

to może się podlacze, co w takim razie zamiast angulara? żeby było tak przyjemnie (albo i lepiej) jak w nim? :P

Pozostało 580 znaków

2015-02-07 17:37
0

http://emberjs.com/ maybe


Hate the sin, love the sinner
edytowany 1x, ostatnio: NoZi, 2015-02-07 17:38

Pozostało 580 znaków

2015-02-07 17:38
3

Ja używam angulara. Jest używalny. Trzeba poświecić jednak dużo czasu na naukę. Jak ktoś robi złożoną aplikację to można trochę utknąć, bo stale pojawiają się dylematy. Zrobić dyrektywę czy powalczyć z wbudowanymi dyrektywami i "spiąć" je w kontrolerze widoku... itp itd.

Walidacja nie jest wg mnie zbyt dojrzała jak na framework tej wielkości. Już nie wspominając dynamicznego rozwoju, ciągle coś nowego się pojawia (trzeba się edukować na bieżąco - v1.4.0 już jest w wersji beta).

Po wyjściu angulara 2.0 prawdopodobnie wszystko stanie na głowie całkiem. Chociaż tu 2-3 tygodnie męki (czyt. nauki) i będzie już dobrze :P. Gorzej z tranformacją kodu z 1.x na 2.x w dużych projektach.

Pewnie za 2-3 lata dojdzie do krystalizacji jakiegoś złotego standardu, bo na razie jest dziki zachód :P

Pozostało 580 znaków

2015-02-07 17:39
2
winerfresh napisał(a):

I test to brutalna prawda. Google Angulara użyło tylko w YT dla PS3. Dodatkowo wiele osób uważa, że to jest taki framework korpo dla JSa.

Trudno się z tym nie zgodzić.

Angular 2.0 wprowadza dużo dobrych zmian i jest nadzieja, ale nie ukrywajmy - mamy wersję 1.4 na horyzoncie, masa aplikacji jest nadal na 1.2 i developerzy mają czasem ręce związane (khym, ui-bootstrap), więc nie zanosi się na razie, żeby zobaczyć coś dojrzałego w Angularze 2.0 w ciągu 2-3 lat.

Polecam Reacta i RxJS. Znajomi dobrze wyrażają się też o Ampersandzie - warto spróbować. Z nowych zabawek Aurelia i Mithril mogą komuś się spodobać. Ale serio - React, jeśli miałbym na coś stawiać.

Pozostało 580 znaków

2015-02-07 18:06
tk
0
Sand24 napisał(a):

Ma swoje mocne strony, ale za dużo jest tych słabych. Jak chcesz usłyszeć jakieś konkrety, to pytaj.

To ja bym poprosil zarowno o podanie tych mocnych jak i slabych stron, bo tak sie sklada, ze przymierzalem sie do uzycia Angulara w pewnym projekcie. I co ma wlasciwie ten caly React czego nie ma Angular? Innymi slowy: dlaczego polecilbys React-a?

No i dodatkowe pytania: czy podczas nauki tego narzedzia popelniles jakies bledy, ktorymi moglbys sie podzielic? Chcialbym uniknac bledow popelnianych przez innych zeby nie musiec pozniej przerabiac zbyt duzej ilosci kodu.

winerfresh napisał(a):

I wszystkich …uj strzeli jak wyjdzie Angular 2.0, który z poprzednim będzie miał wiele wspólnego: nazwę.

Dobrze, ze o tym napisales :) Szkoda tylko, ze na tego Angulara 2 bedzie trzeba troche poczekac - ma wyjsc podobno gdzies pod koniec 2015 roku o ile nie pozniej.

Pozostało 580 znaków

2015-02-07 18:22
2

React wprowadza programowanie reaktywne do JSa. Sprawdź sobie Oma. Wrapper do Reacta napisany w ClojureScript. Ogólnie chodzi o to, że React tworzy wirtualny DOM, na którym się pracuje. Dzięki temu kod jest zmieniany tylko wtedy kiedy trzeba. Om idzie o krok dalej i używa niezmiennych typów danych, dzięki czemu sprawdzenie, czy dany element trzeba zaktualizować to tylko porównanie referencji (über szybkie). Z kolei Angular używa dirty-chekingu do sprawdzenia, czy trzeba coś zaktualizować, co powoduje, że przy większej ilości elementów mogą się pojawić problemy z wydajnością.

Pozostało 580 znaków

2015-02-09 20:32
8
tk napisał(a):

To ja bym poprosil zarowno o podanie tych mocnych jak i slabych stron, bo tak sie sklada, ze przymierzalem sie do uzycia Angulara w pewnym projekcie.

Mocne strony:
1) Mała praca wejścia - opanowanie kilku wbudowanych dyrektyw, koncepcji kontrolerów i serwisów to zabawa na kilka wieczorów, potem dochodzą własne dyrektywy, z którymi już tak łatwo nie jest, ale nadal podstawy dość szybko można ogarnąć
2) Obsługa formularzy jest bardzo przyjemna (włącznie z niezbyt dobrze udokumentowaną walidacją), pod warunkiem, że ich struktura jest dość płaska, tzn. nie ma wielokrotnych zagnieżdżeń, w przeciwnym wypadku łatwo zrobić syf w htmlu i trudniej to się utrzymuje; brakuje tutaj ewidentnie jakiegoś mechanizmu ułatwiającego komunikację między komponentami
3) Jeśli wypracujesz sobie dobrą bazę komponentów, to pewne powtarzalne czynności robi się ekspresowo - Angular nadaje się idealnie do CRUD-owych aplikacji, gdzie masz bardzo dużo powielonych (lub podobnych) rzeczy w interfejsie - łatwiej jest się trzymać zasady DRY
4) Bardzo mocną stroną Angulara są filtry - gdybym miał wybrać jedną rzecz, która mi najwięcej pomogła w przetwarzaniu danych, to chyba właśnie filtry - pozwalają zaoszczędzić masę czasu i są banalne w użytkowaniu
5) Odnoszę wrażenie że osoba backendowa łatwiej odnajdzie się w Angularze niż w innym frameworku, widać sporo przemyślanych patternów; co więcej znam Javowca, który średnio kojarzył JS, a Angulara załapał w tydzień jako tako ;) i kod nie wyglądał źle
6) Duże community i fakt, że sporo już ludzi przeszło przez masę problemów w Angularze sprawia, że dość łatwo znaleźć odpowiedź na większość pytań na stacku i na blogach developerów (inna sprawa, że trzeba umieć odrzucić te mało wartościowe źródła)
7) duże plusy dla ngResource, Restangulara i przyjemnego routingu

Słabe strony:
1) Wydajność - z jednej strony w Angularze dość trudno dojść do problemu kiepskiej wydajności aplikacji - jeśli trzymasz się dobrych praktyk, interfejs jest dobrze skonstruowany pod kątem UX, to możliwe, że temat optymalizacji będzie dla Ciebie obcy; ale jest też druga strona medalu - jeśli danych w widoku jest dość dużo i model jest dość skomplikowany (częste w aplikacjach, które wypluwają jakieś dokumenty jako końcowy wynik operacji "analityka"), to Angular potrafi dostać niezłej czkawki przez nieszczęsne dirty-checking, problemy wydajnościowe są też zauważalne na urządzeniach mobilnych (ostrożnie z animacjami ;)) [http://www.binpress.com/tutor[...]with-simple-optimizations/135 i https://www.airpair.com/angul[...]erformance-large-applications odnośnie typowych pułapek]. Czasami jednak to nie wystarczy i teoretycznie można napisać jakiś moduł różnicowy w Angularze (operacja z socketami w Angularze to porażka z powodu właśnie dirty-checking), ale nie powinno być tak, że framework ogranicza i utrudnia, zamiast ułatwiać.
Przykładowe problemy:

  • aplikacja ma infinite scroll (coś jak 9gag) i nie można użyć bindonce, bo mamy mieć możliwość modyfikacji elementów na nieskończonej liście - kończymy na hackowaniu ngRepeat
  • aplikacja czatu z listą użytkowników online, która odświeża się za pomocą socketu i po najechaniu na użytkownika możemy w popupie podejrzeć jego dane czy powiększyć avatar (whatever); modyfikacja listy (i idący dalej $digest) powoduje odświeżenie popupa (i w pesymistycznym przypadku jego mignięcie lub wyłączenie) - ale przecież popup nie powinien zależeć od listy użytkowników nie?
    2) $scope - różne możliwości dziedziczenia, dynamiczny scoping (problemy, gdy jedna dyrektywa wbudowana tworzy nowy scope, inna nie) - rozwiązano to za pomocą controllerAs i bindToController, ale problem nadal istnieje, po prostu na razie otrzymał opcjonalną łatkę, z której nie każdy korzysta (można powiedzieć, że to problem developerów ;))
    3) dependency injection - czyli 4 sposoby zapisu tego samego (wliczając ngAnnotate), w tym jeden nie działa przy minifikacji kodu; sama idea fajna, szkoda jedynie, że moduły w Angularze nie do końca poprawnie działają i ludzie używają RequireJS albo Browserify
    4) niejasne nazewnictwo, np. factory, service
    5) zbyt duża złożoność momentami, np. istnieje 5 metod (chyba że o czymś nie wiem?) definiowania serwisów i nie jestem w stanie znaleźć uzasadnienia na to; definicja dyrektywy jest ogromna jak na tak mała koncepcję (PreLink, PostLink, Compile, ech) i ciągle budzi wątpliwości po co to wszystko
    6) wyciszanie błędów w Angular expressions (powodzenia ze śledzeniem błędów popełnianych przez początkujących)
    7) komunikaty o błędach - miałem taką sytuację, że był błąd w backendzie z nagłówkiem HTTP i wywołanie metody zwróciło normalnie status 200, dane przyszły, można wywołać w kliencie restowym bez problemu - niby wszystko ok; Angular rzucił coś w stylu "unexpected token" i tyle; często pojawiają się też niejasne komunikaty z dependency injection - pokazuje, że jest w jednym miejscu źle wstrzyknięta zależność, a okazuje się być w templacie dyrektywy - cool;
    8) debuggowanie - poniekąd związane z powyższym, ale niekoniecznie - chodzi o kilometrowy stacktrace (wtf?) - duży minus
    9) a propos dependency injection - kolizje nazw serwisów, kontrolerów i dyrektyw - anyone? :) radzę prefixować wszystkie nazwy - cholernie uciążliwe
    10) brak warstwy modelu - jeśli model jest lekki, to pewnie nie jest to problemem, bo wystarczy zdefiniować prosty obiekt w serwisie wraz z ngResource, $scope przetrzymuje odwołanie do niego i teoretycznie jest ok, ale co jeśli jest inaczej? pozostaje Backbone lub Breeze ze znanych mi rozwiązań
    11) Komunikacja między komponentami, które nie są w hierarchii parent-child (a i te które są dość dziwnie się komunikują - chodzi rzecz jasna o metody w kontrolerze dyrektywy - blech) - od biedy sposób z zapisem stanów w serwisach jest ok, ale konieczność tworzenia serwisu na potrzeby przekazania stanu już niekoniecznie, eventy mnie nie przekonują (szczególnie $rootScope.$broadcast) - trudno je testować w tej postaci, nie ma dobrej metody dokumentowania i powodują czasem side-effecty, $watch na modelu może spowodować problemy wydajnościowe (szczególnie z opcją głębokiego obserwowania - nie wiem czy dobrze to ująłem po polsku ;)), jeszcze gorzej z $watchCollection
    12) brak wsparcia dla server renderingu; musi być kompromis między SPA a tym, co jest renderowane po stronie serwera; idealne imho póki co wyjście z sytuacji, to na każdy url zwracać wyrenderowany widok (nie sam index.html), a w momencie przechodzenia między urlami w aplikacji kontrolę nad tym ma SPA framework; jest to bardzo SEO-friendly i pozwala uniknąć sytuacji, że działanie aplikacji jest blokowane przez długie tworzenie instancji - odczuwalne już w 3G (!); niestety w Angularze jest to dość trudne w osiągnięciu (delikatnie mówiąc); no i nie ma problemu, jeśli ktoś nie ma włączonej obsługi JS z jakiegoś względu
    13) Zewnętrzne dyrektywy potrafią być naprawdę tragicznie napisane. Można tutaj winić programistów, w ekosystemie jQuery w końcu też jest masa fajnych zabawek, ale koszmarnie napisanych. Problem w tym, że zły kod jest potęgowany hackami, bo ktoś nie wie jaki jest cykl życia komponentów (i nie ma co się dziwić, jeśli nie jest on "explicit", jak masa rzeczy we frameworku) i robi $timeout, albo niepotrzebnie stosuje $watch. W konsekwencji nowa osoba w świecie Angulara może mieć duże problemy ze zrozumieniem kodu i nie ułatwia tego masa abstrakcji. "Too much magic" można powiedzieć, bo w końcu niby to jedynie JS, tylko dlaczego osoby dobrze znające JS mają problemy ze zrozumieniem kodu w Angularze, a w takim React już nie? Warto się nad tym zastanowić.
    14) Jeśli w zespole mamy programistów o nierównych umiejętnościach, to możemy łatwo przejechać się na Angularze, bo opanowanie różnych pułapek potrwa minimum pół roku, a dla niektórych projektów to może być duże ryzyko.

Moim zdaniem naukę Angulara lepiej poświęcić na doszlifowanie JS-a, wzięcie czegoś typowo do widoku (np. Reacta) i nauczenie się pisania dobrych, małych i skalowalnych komponentów. Bo w tym największy problem leży u niedoświadczonych programistów. Co z tego, że ktoś nauczy się pisania dyrektyw, jak będą one nadal "tightly coupled", kompletnie niereużywalne i z zaciemnioną logiką (która pewnie będzie umieszczona w Angularowym expression - bo się da!).

Dzięki za wyczerpującą odpowiedź :) - tk 2015-02-09 21:18
Nie ma sprawy. :) - Sand24 2015-02-10 07:17

Pozostało 580 znaków

2015-02-09 23:24
0

10) brak warstwy modelu - jeśli model jest lekki, to pewnie nie jest to problemem, bo wystarczy zdefiniować prosty obiekt w serwisie wraz z ngResource, $scope przetrzymuje odwołanie do niego i teoretycznie jest ok, ale co jeśli jest inaczej? pozostaje Backbone lub Breeze ze znanych mi rozwiązań

Sam używam Breeze do ORM client-side. John Papa zrobił nawet liba, ktory robi tzw. "work in progress" czyli wykorzystanie mechanizmu cachowania całych obiektów w pamięci (Breeze) + robienie tego w locie. Przydatne, ale ogarniecie Breeze + tego dodatkwoego liba zajmuje trochę czasu.

Z drugiej strony, gdy korzysta się z Breeze, to odpada robienie rozbudowanego RESTowego API, bo Breeze sam będzie sobie konstruował zapytania do serwera (np. mongodb + mongoose). Mimo męki z konfiguracją polecam :)

12) brak wsparcia dla server renderingu; musi być kompromis między SPA a tym, co jest renderowane po stronie serwera; idealne imho póki co wyjście z sytuacji, to na każdy url zwracać wyrenderowany widok (nie sam index.html), a w momencie przechodzenia między urlami w aplikacji kontrolę nad tym ma SPA framework; jest to bardzo SEO-friendly i pozwala uniknąć sytuacji, że działanie aplikacji jest blokowane przez długie tworzenie instancji - odczuwalne już w 3G (!); niestety w Angularze jest to dość trudne w osiągnięciu (delikatnie mówiąc); no i nie ma problemu, jeśli ktoś nie ma włączonej obsługi JS z jakiegoś względu

To jest prawdziwy pain-in-the-ass. Z drugiej strony apki angularowe często są schowane za panelem logowania i SEO ich nie dotyczy.

edytowany 3x, ostatnio: członek zarządu, 2015-02-09 23:31

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0