Angular - jak sie z tym pracuje

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?

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.

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.

0

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

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

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ć.

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.

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ą.

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/tutorial/speeding-up-angular-js-with-simple-optimizations/135 i https://www.airpair.com/angularjs/posts/angularjs-performance-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?
  1. $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 ;))
  2. 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
  3. niejasne nazewnictwo, np. factory, service
  4. 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
  5. wyciszanie błędów w Angular expressions (powodzenia ze śledzeniem błędów popełnianych przez początkujących)
  6. 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;
  7. debuggowanie - poniekąd związane z powyższym, ale niekoniecznie - chodzi o kilometrowy stacktrace (wtf?) - duży minus
  8. a propos dependency injection - kolizje nazw serwisów, kontrolerów i dyrektyw - anyone? :) radzę prefixować wszystkie nazwy - cholernie uciążliwe
  9. 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ń
  10. 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
  11. 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
  12. 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ć.
  13. 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!).

0
  1. 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 :)

  1. 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.

1

Zastanawiające sie jak się to wszystko zmienia. Jeszcze w 2013 Angular dopiero zyskiwał na popularności, był wielkim hitem, next big thing.
W 2014 już stał się standardem. Ciężko było znaleźć ogłoszenie o pracę w JavaScript, które nie wymagało znajomości Angulara.
A teraz na początku 2015 z jednej strony " Angular ostatnio otrzymuje dużo krytyki i to konstruktywnej.", z drugiej strony rosną coraz to nowe frameworki, które być może będą "następcami angulara".

Ciężka jest dola frontendevelopera, bo żeby być na bieżąco, trzeba się co najmniej co miesiąc (albo częściej) uczyć nowego frameworka.

Co do pracy z samym angularem:

  • łatwo ustrukturyzować kod
  • można tworzyć własne komponenty (tu nazywane "dyrektywami")
  • dużo rzeczy działa magicznie
  • data biiiiinding xD :P ^^
  • nic nie jest jasne, wszystko można zrobić na x różnych sposobów

  • skomplikowana architektura, dziwna dychotomia service/factory, dziwne znaczki (@, =, &), dużo "angular way", który polega głównie na udziwnieniach. Dużo magicznych rzeczy, które dzieją się pod maską.

  • twórcy angulara wykazali się duuuuużą krótkowzrocznością i zamiast opierać się na już istniejących bibliotekach do robienia modułów (moje ulubione CommonJS+Browserify), stworzyli swój własny system modułów, niekompatybilny z niczym: http://xkcd.com/927/

  1. 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

to mnie zastanawia. w sensie używają Browserify razem z Angularem zamiast pisać angular.module? Da się tak w ogóle?

  • brak pełnego wsparcia javascriptowych IDE dla angulara (ale to truizm, bo przypuszczam, że żaden framework JS nie ma pełnego wsparcia IDE), w wyniku czego ciężko ogarnać duży projekt (no chyba, że to projekt, w którym jest się od początku i się zna go jak własną kieszeń. To nawet w notatniku pewnie można by sobie poradzić)

? logika w warstwie widoku (dałem pytajnik, bo nie wiem jak to oceniać i nie wiem gdzie postawić granicę między normalnym templatingiem a logiką. Myślę, że to zależy dużo od tego, jak sami to zaprojektujemy)

? style CSS w warstwie widoku (angular czasami zachęca/wymusza pisanie inline stylów na zasadzie ng-style="jakies wyrazenie angularowe"). ale znowu, myślę, że jak się chce, to można tego uniknąć.

0
członek zarządu napisał(a):

Przydatne, ale ogarniecie Breeze + tego dodatkwoego liba zajmuje trochę czasu.

No właśnie, problem w tym, że w Angularze na początku wszystko robi się łatwo i przyjemnie, ale gdy napotka się ścianę to rozwiązania problemów nie są trywialne i często wymagają dużej pracy wejścia jak ze wspomnianym Breeze. :)

LukeJL napisał(a):

Ciężka jest dola frontendevelopera, bo żeby być na bieżąco, trzeba się co najmniej co miesiąc (albo częściej) uczyć nowego frameworka.

Nie przesadzałbym, Angular to nadal w pełni użyteczny framework, po prostu ma swoje zastosowania. Niestety dużo firm stawia na niego myśląc, że nada się do każdego następnego projektu, a tak nie jest. Do stabilizacji w community JS jeszcze daleko, o ile kiedykolwiek nastąpi i ma to swoje zalety i wady. Na pewno nie można się nudzić i fajnie jest eksperymentować. ;) Dlatego warto przede wszystkim dobrze znać JS-a i podstawowe wzorce, wtedy opanowanie kolejnej biblioteki/frameworku nie zajmie dużo czasu (aczkolwiek "angular way" to też spory problem).

członek zarządu napisał(a):

w sensie używają Browserify razem z Angularem zamiast pisać angular.module? Da się tak w ogóle?

Nie zamiast angular.module, a razem. Przykład: http://benclinkinbeard.com/talks/2014/ng-conf/#/19

członek zarządu napisał(a):

brak pełnego wsparcia javascriptowych IDE dla angulara (ale to truizm, bo przypuszczam, że żaden framework JS nie ma pełnego wsparcia IDE)

Polecam Webstorma do Angulara. Jest trochę "ciężkawy", ale daje radę. Dobrze sobie radzi z autocomplete.

0

Nie zamiast angular.module, a razem. Przykład: http://benclinkinbeard.com/talks/2014/ng-conf/#/19

nooo, to jest mocne. Można powiedzieć, że jak zobaczyłem te slajdy, to doznałem olśnienia i momentu "aha". (już wcześniej, jak o tym napisałeś, to przegooglowałem angularjs browserify i znalazłem tę stronę). O ile używałem angulara, i używałem browserify, to nigdy nie wpadłem na to, żeby te dwie rzeczy połączyć ze sobą (naprawdę solidne zaciemnienie umysłu musiałem mieć). A jakby popatrzeć to daje to niesamowite możliwości uporządkowania kodu w projekcie i wydzielania do osobnych plików, to co bez tego by się pisało chaotycznie w jednym pliku i ciągiem "angular.module(...).controller(...).controller(...).directive(....)" etc.

Polecam Webstorma do Angulara. Jest trochę "ciężkawy", ale daje radę. Dobrze sobie radzi z autocomplete.

Owszem, jest to ciekawe IDE (i chyba najlepsze do JS, jakie obecnie jest), ale nie przesadzałbym z jego wsparciem dla Angulara. Chociaż na szczęście rozwija się cały czas, teraz jest już można ściągnąć wersję 10 w early access (której jeszcze nie testowałem). Chociaż - moim zdaniem jeszcze z rok, czy dwa upłynie, zanim się to przerodzi w coś naprawdę dobrego (o ile nie popadną w marazm. Ta firma, JetBrains, staje się powoli monopolistą jeśli chodzi o IDE do języków programowania (IntelliJ, PhpStorm, PyCharm etc.), a jak wiadomo jak ktoś staje się monopolistą, to zwykle stopuje rozwój i spoczywa na laurach, bo nie ma konkurencji, którą by musiał prześcignąć).

0

Ta firma, JetBrains, staje się powoli monopolistą jeśli chodzi o IDE do języków programowania (IntelliJ, PhpStorm, PyCharm etc.), a jak wiadomo jak ktoś staje się monopolistą, to zwykle stopuje rozwój i spoczywa na laurach, bo nie ma konkurencji, którą by musiał prześcignąć).

Większość IDE od JetBrains to to samo, tyle że inaczej skonfigurowane. Mam tutaj na myśli IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, RubyMine itp itd IntelliJ IDEA z zestawem wtyczek oferuje praktycznie wszystko to co cały ten zestaw naraz. Całkowicie osobnym produktem jest za to Resharper, który jest chyba zaklepany w C#, a nie w Javie, z wiadomych powodów.

JetBrains nie są jedynymi, którzy tak robią (czy nadają nową nazwę dla produktu z wtyczkami). Jest np Aptana Studio, które jest z grubsza specjalnie skonfigurowanym Eclipsem.

0
winerfresh napisał(a):

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

skad takie info ?

0

Podaj przykład aplikacji napisanej przez Google używającej Angulara. Sami by się tym pochwalili chyba https://builtwith.angularjs.org/. FB używa Reacta, no cóż, na FB i to z całkiem dobrym skutkiem.

0

Nie wiedziałem jak odróżnić, która aplikacja jest napisana w Angularze. Na co dzien w pracy programuje w javie , ale chcialbym po godzinach stworzyc swoja apke i do tego potrzebna mi jest takze wiedza z frontendu. Biorac pod uwage powyzsze uwagi to o duzo lepiej zaczac sie uczyc Reacta zamiast Angulara, tak ? W przypadku obu bylaby to nauka od zera.

1

Angular jest znacznie bardziej "przyjazny" ludziom piszącym w Javie. Masz większość "technik" używanych w Javie jak DI, fabryki, etc. Dodatkowo Angular jest znacznie prostszy do ogarnięcia przez ludzi z FE.

Z drugiej strony React ma znacznie wyższy próg wejścia, ale zapewnia większą wydajność i przy zastosowaniu odpowiednich technik masz znacznie większą segmentację aplikacji.

Dodatkowo React nie jest "frameworkiem" a raczej biblioteką, która jest używana w technice pisania aplikacji we Fluksie.

Ogólna odpowiedź na pytanie "co lepsze" nie istnieje. Musisz samemu zobaczyć co Ci bardziej podchodzi.

0

A co sądzicie o zastosowaniu Angulara w tworzeniu aplikacji mobilnych? Mam na myśli projekty typu IONIC framework. Mam podejrzenia, ze to moze byc nisza, w ktorej ta technologia moze sie wysmienicie sprawdzic (lepiej niz w typowych portalach). Z reguly aplikacje mobilne sa mniejsze niz portalowe i ryzyko zwiazane z przepisaniem / utrzymywaniem starego kodu za kilka lat jest mniejsze. Ewentulne koszta migracji rowniez. Nie wspominajac o tym, ze piszac aplikacje mobilna raczej mamy mniejsze prawdopodobienstwo koniecznosci obslugi bardzo starych przegladarek.

Ponadto szansa na kolizje nazw np. przy dependency injection jest znacznie mniejsza.

Jakie jest Wasze zdanie? Mam zamiar to wyprobowac jako dopelnienie backendu pisanego w Javie. Licze na krotsza sciezke uczenia sie niz w przypadku czystego PhoneGap / innych cross-platformowek.

http://ionicframework.com/

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