Co zamiast Angulara? Framework dla JS

Jeszcze półtora roku temu robiłem projekt w AngularJS 1, a teraz wyszła już 2 i 4.
Zastanawiam się, co wybrać do następnego projektu, troche mnie denerwuje szybkość wychodzenia kolejnych wersji, których trzeba się od nowa uczyć. Jestem programistą backendu a frontendu potrzebuje żeby był a nie żeby przepisywać go na nowe wersje co chwila. Zwłaszcza że to nie tylko podbicie wersji i drobne zmiany ale zmienia się praktycznie wszystko i wręcz od nowa trzeba się uczyć.
Do CV też wpisać nie wypada jak się zna dwie wersje wstecz.
Szukam więc frameworka bardziej dojrzałego. Jest taki, czy nie ma (sensownej) konkurencji dla Angulara?

Wszystko to samo ;-)
Vue, React, setki innych...

angular 2-4 to tylko niewielkie zmiany taki drobny update
angular 1 to angularJS i będzie cały czas rozwijany

Jak cię denerwują takie zmiany to albo się przyzwyczaisz do tego albo porzucisz front a w najgorszym wypadku całe programowanie.

angular 1 to angularJS i będzie cały czas rozwijany 

?? To znaczy, że nadal można sie tego uczyć?? Na Helion.pl są nieaktualne książki o Angular w różnych wersjach, ale okazuje się, że nadal aktualne?...

mr_jaro napisał(a):

angular 2-4 to tylko niewielkie zmiany taki drobny update
angular 1 to angularJS i będzie cały czas rozwijany

Jak cię denerwują takie zmiany to albo się przyzwyczaisz do tego albo porzucisz front a w najgorszym wypadku całe programowanie.

We froncie nie robię co napisałem w poście :)

Czy ja wiem czy takie drobne zmiany? Zdaje mi się że Angular 4 wymusza pisanie w TypeScripcie? Do tego format plików, templatek się dość istotnie zmienia.

Wesoły Lew napisał(a):

Czy ja wiem czy takie drobne zmiany? Zdaje mi się że Angular 4 wymusza pisanie w TypeScripcie? Do tego format plików, templatek się dość istotnie zmienia.

drobne różnice między angular 2 i 4 bo to jak update z 1.4 do 1.5

angular 1 jest dalej rozwijany pod nazwą angularJS zbyt wiele projektów powstało które są nadal rozwijane i których nie opłaca się przepisywać dlatego dalej będzie to rozwijane, zapowiedziany jest już angularJS 1.7

angular 4 zwany od teraz po prostu angular jest napisany w tyscripcie i jest to zupełnie inny framework.

@mr_jaro:
No właśnie, mnie czekała by przesiadka z 1 na 4. Czyli różnic pewnie nie tak mało? Pewnie nowe koncepcje itd?
W ile czasu pójdzie ogarnąć zmiany + typescripta
No a opłaca się w ogóle w Angular 1 zaczynać projekt teraz? Chyba średnio.
A jak siedzisz we frontendzie to orientujesz się czy szykuje się kolejny fork, jak z 1 do 4? Bo po prostu zastanawiam się czy opłaca mi się tego uczyć czy może pójść w kierunku takiego Reacta. Właśnie chodzi mi żeby ewentualne zmiany, updaty to były rzeczy drobne jak np updaty Javy lub Springa a nie że framework napisany od nowa jak Angular.

nie licz w najbliższym czasie na to, że we froncie będą drobne zmiany, technologie mające 2 lata są uznawane za staroć. Java się dynamicznie rozwijała ileś lat temu, front się rozwija teraz.

mr_jaro napisał(a):

nie licz w najbliższym czasie na to, że we froncie będą drobne zmiany, technologie mające 2 lata są uznawane za staroć. Java się dynamicznie rozwijała ileś lat temu, front się rozwija teraz.

Ok dzięki, zostanę więc przy Angularze, i tak mniej będzie do ogarnięcia z 1 do 4 niż całego Reacta zapewne.

@mr_jaro
A skoro siedzisz w JS to jak widzisz ogółem temat frameworków? Angular jest Twoim ulubionym? Używałeś Reacta i innych i możesz porównać? Co czeka nas Twoim zdaniem za parę lat? Wszyscy będą pisać w TypeScripcie czy jakąś inną przyszłość wróżysz?
Sorry za tyle pytań ale właśnie kojarzę Cię z przeglądania tego forum.
Chętnie przeczytam też odpowiedzi innych :)

Ok dzięki, zostanę więc przy Angularze, i tak mniej będzie do ogarnięcia z 1 do 4 niż całego Reacta zapewne.

W React akurat nie ma wiele do ogarnięcia. Przynajmniej jeśli chodzi o ogólne API, bo potem może się zdarzyć, że będziesz umiał zaklepać w React komponenty (bo to bardzo łatwe jest), ale będziesz miał problemy typu "jakiś komponent się odświeża niepotrzebnie po kilka razy i to ma zabójczy efekt dla wydajności" albo "komponent się nie odświeża w ogóle i pokazuje stare dane". I będziesz musiał wnikać w szczegóły, debugować co i kiedy się odświeża, a kiedy nie (więc będziesz musiał ogarnąć cykl życia komponentów, sposoby w jaki sposób są odświeżane itp.).

Tylko, że synchronizacja współdzielonego mutowalnego stanu jest zawsze trudna. W zasadzie wszystkie frameworki JSowe rozwiązują ten sam problem - synchronizację wewnętrznego stanu aplikacji z elementami DOM, które się wyświetlają na ekranie. I różnia się po prostu tym, jak to robią - wzorzec obserwatora w Backbone, two-way binding w AngularJS, unidirectional data flow z React...

Tu zawsze będą jakieś problemy. I dlatego tak wiele frameworków powstaje w JS, bo ciągle się okazuje, że dane podejście do synchronizacji stanu jest słabe i że nowy framework rozwiązuje to w inny sposób (jednak również w sposób nieidealny).

Jestem programistą backendu a frontendu potrzebuje żeby był a nie żeby przepisywać go na nowe wersje co chwila

Jeśli robisz coś małego, to każdy framework jest dobry (teraz stawiałbym na Reacta, Facebook go używa w produkcji, więc pewnie nie zniknie tak szybko jak kolejna zabawka Google (niestety Google ma skłonność do ubijania swoich własnych wytworów jak im się znudzą)). Z kolei jak robisz coś dużego to i tak okaże się, że masz większe problemy niż wybór frameworka.

Dzięki @LukeJL za odpowiedź! Dobre podsumowanie jeśli chodzi o istnienie tych frameworków.
Ja potrzebuje frameworka pod projekt głównie backendowy, ale chciałbym by wszystko się ładnie i dynamicznie wyświetlało. Zobaczę Reacta, mam nadzieję, że mi się spodoba. Przy Angularze 4 mam wrażenie pewnej zbytniej komplikacji. Nie czułem tego ucząc się AngularaJS. Niby faktorki wywalone, ale składnia np. templatek bardziej mi tam pasowała.

@Wesoły LEw

Przy Angularze 4 mam wrażenie pewnej zbytniej komplikacji.

I słusznie.

Ja patrząc na dane rozwiązanie zwracam uwagę na:

• ilość JSa w JSie (jak wiele kodu który napiszesz będzie niezależna od frameworka),
• signal to noise ratio - jaka część kodu to boilerplate a ile logiki biznesowej,
• testowalność - czy da się łatwo testować bez mockowania i specjalnych utilsów specyficznych dla frameworka,
• deklaratywność lub jej brak,
• sposób obsługi efektów ubocznych,
• SRP, DRY, KISS - czy rozwiązanie temu sprzyja czy nie,
• kompletność rozwiązania (SSR, mobile, universal JS) - nie zawsze wymagane,
• flow aplikacji, łatwość rozumowania o działaniu aplikacji, debugowalność, dev toolsy,
• paradygmat (w sumie wiele z powyższych punktów jest jego pochodną).

Poza tymi ściśle technicznymi i koncepcyjnymi punktami ważne są też:

• społeczność,
• oferty na rynku pracy,
• ilość gotowych komponentów itp,
• stabilność.

Przy czym pierwsza lista jest moim zdaniem ważniejsza - framework z dużą społecznością, sporym hypem i udziałem w rynku, ale bez dobrych fundmentów to droga do nikąd - prędzej czy później umrze, a umiejętność nabyte podczas pracy z nim będą niewiele warte.
Takim smutnym przykłądem jest tu AngularJS, nowemu Angularowi wróżę to samo.

React + Redux/MobX i Vue są wg mnie gdzieś pośrodku - dużo rzeczy jest tam ok, ale wiele można poprawić, ze wzgledu na stosunek jakości rozwiązania do popularności (pierwszej listy do drugiej) na Twoim miejscu właśnie w jeden z nich inwestowałbym swój czas (ze wskazaniem na ekosystem Reacta).

A po godzinach uczyłbym się FRP i czegoś w stylu Cycle.js - to może być wg mnie "next big thing" ;)