Wybór narzędzi do pracy - jak przebić się przez szum informacyjny?

Stanąłem ostatnio przed wyborem frameworka do nowego projektu - aplikacji klienckiej na przeglądarki. Na co dzień zajmuję się głównie pisaniem oprogramowania backendowego, frontendowy stack technologiczny którego używałem do tej pory jest już dość archaiczny i wymaga zmiany. Jestem trochę przytłoczony mnogością opcji z jakiej przyszło mi wybierać narzędzia. O ile w takim .NET czy Go zazwyczaj jest 1 sposób (góra 2) na zrobienie czegoś, tak w przypadku frameworków JS to kogo zapytać to powie co innego

Z tego względu nie pytam was o to co byście mi polecali jako framework, ale zamiast tego chciałbym się od was dowiedzieć gdzie szukacie porady gdy podejmujecie taką decyzję? Czy jesteście w stanie polecić jakieś źródło informacji które:

1. Nie ulega łatwo trendom
2. Nie jest sponsorowane
3. Pozwala na odsianie szumu od faktycznej informacji

?

Wydaje mi się, że najlepszym rozwiązaniem będzie wybrać 3 najpopularniejsze i coś napisać, albo chociaż zacząć ten projekt. Ja do JSa przyszedłem z .NET i najbliżej w kodzeniu miał Angular. Bardzo mi się podoba Svelte, ale już składnia kompletnie inna i ciężko mi się przestawić z Angulara.

Taki sam problem miałem w przypadku wyboru technologii mobilnej. Przeszedłem przez Xamarina, Natywne (Kotlin), aż doszedłem do Fluttera. A zdecydowało o tym szybkość rozwiązywania danego problemu i to samo tyczyło się Angulara. Im mniej czasu spędziłem na dokumentacji jak coś napisać tym bardziej decydowało to o wyborze.

Koniec końców i tak najlepiej jak wybierzesz to co najpopularniejsze; ze względu na wielkość społeczności mozesz być pewny wsparcia, tego że nie będziesz musiał podstawowych problemow rozwiązywać sam, tego że przeszły przez spory feedback i mają poprawione co się dało. Do tego znajdziesz generatory szablonów które ci postawią solidny "hello world" ze wszystkim co potrzebujesz i gotowe na deploy na produkcje.
Możesz zaryzykować wybór jakiegoś mniejszego frameworka ale ryzykujesz że w pewnym momencie zostaniesz z problemem sam, zderzysz sie ze ścianą i będziesz musiał robić jakieś nasty hacki i przegrzebywać sie przez kod frameworka żeby znaleźć obejście.
Tak naprawdę masz tylko 3 opcje. Proponuję spędzić po dwie godziny z kilkoma frameworkami i wybrać co ci pasuje. Prawdopodobnie wybierzesz to co jest najbardziej podobne do tego co znasz.
Nie ma źródła które rzetelnie i bezstronniczo przeszło i oceniło wszystkie dostępne mało popularne frameworki.

1. Nie zaczynaj projektu od wyboru frameworka ani biblioteki
2. Zostaw sobie miejsce na to żeby nie podejmować żadnych decyzji na początku, odrocz je na późniejszy etap projektu.
3. Zacznij od najbardziej podstawowej funkcjonalności jaką jesteś w stanie zrobić.
4. Napisz jakąś prostą funkcjonalność najprościej jak się da, bez frameworka. Zakodź sam najbardziej podstawowe elementy.
5. Pokaż klientowi i spytaj czy taki feature może być.
6. Powtórz jeszcze kilka razy punkt 2.
7. po kilku iteracjach będziesz wiedział miej więcej jaki rodzaj funkcjonalności będzie dochodził do Twojej aplikacji.
8. Będziesz potrzebował napisać dodatkowe elementy (logowanie, router, bezpieczeńśtwo, etc.). Teraz możesz dodać bibliotekę i framework, ale najlepiej dodaj go tak, żeby nie związać go ze swoją aplikacją za bardzo (np. korzystając z dependency inversion).

Zostaw sobie miejsce na to żeby nie podejmować żadnych decyzji na początku, odrocz je na późniejszy etap projektu.

@Riddle Jak w takim razie do tego podejść? Faktycznie, zazwyczaj podchodzę do tego tak (realizując funkcjonalność na backendzie), że piszę logikę biznesową wraz z testami w oddzielnych klasach/modułach, dopiero potem endpointy które wypluwają wynik i implementację obsługi zewnętrzych usług. Na frontendzie nie bardzo wiem jak się do tego zabrać, może to wynika po prostu z braku doświadczenia.

Z tego co widzę już teraz to różne frameworki JS używają różnych języków. Angular używa TypeScripta, w React widzę pliki z rozszerzeniem jsx (jakieś rozszerzenie JS'a?), są też frameworki które używają czystego JS'a. Takiego kodu TS nie da się użyć bezpośrednio w przeglądarce - trzeba go najpierw przekształcić na czysty JS jakimś narzędziem budującym projekt (webpack?). Tu też widzę że różne frameworki preferują różny stack. Mógłbym podjąć decyzję o pisaniu logiki biznesowej w TS, ale to utrudnia potem przejście na frameworki które na tym nie bazują - musiałbym potem porzucić wypracowany wcześniej sposób budowania projektu i przekształcić pliki na odpowiedni format.

iteredi napisał(a):

Zostaw sobie miejsce na to żeby nie podejmować żadnych decyzji na początku, odrocz je na późniejszy etap projektu.

@Riddle Jak w takim razie do tego podejść? Faktycznie, zazwyczaj podchodzę do tego tak (realizując funkcjonalność na backendzie), że piszę logikę biznesową wraz z testami w oddzielnych klasach/modułach, dopiero potem endpointy które wypluwają wynik i implementację obsługi zewnętrzych usług. Na frontendzie nie bardzo wiem jak się do tego zabrać, może to wynika po prostu z braku doświadczenia.

No po pierwsze, zaakceptuj fakt że kod się zmienia. To jest całkowicie normalne napisać na początku kod, który wiesz że i tak będziesz musiał usunąć. Celem tutaj jest mieć początkową wersję aplikacji której możesz używać. Np. piszesz bardzo prymitywną formę logowania, pokazujesz klientowi, on Ci pisze kilka feature'ów które chce, mijają tygodnie, lub miesiące, i potem przerabiasz logowanie na coś bardziej wyrafinowanego. To jest perfekcyjnie okej, nikt nie pisze dobrych rozwiązań za pierwszym razem. Najpierw należy napisać coś szybko, prosto, tanio; i potem ewentualnie poprawić jeśli jest taka potrzeba. Prosto szybko i tanio, ale dobrze - czyli z testami, z refaktorem, z odpowiednimi nazwami. Nie rób syfu.

Po drugie, nie podejmuj ważnych decyzji na początku projektu - zostaw sobie otwarte drzwi, żeby podjąć decyzje później. Jeśli możesz odroczyć wybór framework'a albo technologii na późniejszy moment - zrób to.

iteredi napisał(a):

Z tego co widzę już teraz to różne frameworki JS używają różnych języków. Angular używa TypeScripta, w React widzę pliki z rozszerzeniem jsx (jakieś rozszerzenie JS'a?), są też frameworki które używają czystego JS'a. Takiego kodu TS nie da się użyć bezpośrednio w przeglądarce - trzeba go najpierw przekształcić na czysty JS jakimś narzędziem budującym projekt (webpack?). Tu też widzę że różne frameworki preferują różny stack. Mógłbym podjąć decyzję o pisaniu logiki biznesowej w TS, ale to utrudnia potem przejście na frameworki które na tym nie bazują - musiałbym potem porzucić wypracowany wcześniej sposób budowania projektu i przekształcić pliki na odpowiedni format.

Ja zazwyczaj zaczynam od najprostszej wersji jaką mogę, najczęściej jest to vanilla-js, ta old-school z document.createElement(). Napisanie tego jest bardzo szybkie, bo począkowe wersje nie mają prawie żadnych funkcjonalności. Nie koniecznie musi być vanilla-js - chodzi po prostu o najszybsze i najtańsze stworzenie początkowej wersji, ale tak żeby być otwartym na późniejszą zmianę tej decyzji. Dlatego nie zaczynam od żadnych scaffoldów - bo jak wygeneruję projekt np. react native; to zmienić to w późniejszym etapie np. na angular jest niemalże niemożliwe.

Potem zbieram feedback od klienta, i dowiaduje się czego potrzebuje - jak bardzo interkatywna ma być strona, czy są powody przypuszczać że będzie chciał PWA czy nie; etc. Piszę widok w taki sposób, żeby odseparować logikę widoku od prezentacji widoku - tak żebym później mógł zmienić vanilla-js na react, SSR, czy jakąś inną technologię, ale tak żeby nie musieć tego pisać od nowa. Bardzo pomaga w tym polimorfizm i SRP.

Wybieranie stacku technologicznego, jak jeszcze dobrze nie wiesz jak będzie wyglądała aplikacja, jest średnie. To trochę tak jakbyś pakował ubrania na podróż, ale jeszcze nie wiesz gdzie.

• Cześć forumowicze, czy na moją wycieczkę powinienem spakować parasol słoneczy czy raczej kurtkę zimową?
• A gdzie jedziesz?
• Nie wiem, ale chciałbym zdecydować już teraz co spakować.

To tak samo wygląda jak pytasz o dobór stacku technologicznego na początku projektu. Nie wiesz jak będzie wyglądał, nie wiesz dokładnie z jakimi problemami się spotkasz, nie wiesz na czym zależy klientowi - ale chcesz podjąć ważną decyzję którą jeszcze będzie trudno zmienić w przyszłości. No tak się nie robi. Najpierw ustal jak będzie wyglądała aplikacja i co będzie miała robić - ale jak to zrobić na początku? No musisz napisać minimum aplikacji żeby klient mógł po niej poklikać, ale trzeba to dostarczyć szybko, i tanio; ale tak żeby nie zamknąć się na zmianę decyzji (tutaj wkracza polimorfizm i Dependency Inversion), oraz tak żeby sobie nie stawiać kłód pod nogi w dalszym developmencie (tutaj wchodzą testy, refaktor, dobre nazwy i SRP). I oczywiście tego się nie robi raz, tylko ciągle. Wprowadzasz małą prostą zmianę, pokazujesz klientowi, zbierasz feedback, robisz kolejną małą zmianę, etc.

Ważna dewiza: na początku każdego projektu, wiesz o nim najmniej. Z czasem i z pracą, wiesz o projekcie coraz więcej. Więc decyzje o stacku i frameworku lepiej podjąć później, wtedy kiedy będziesz miał więcej wiedzy.

Riddle napisał(a):

1. Nie zaczynaj projektu od wyboru frameworka ani biblioteki
2. Zostaw sobie miejsce na to żeby nie podejmować żadnych decyzji na początku, odrocz je na późniejszy etap projektu.
3. Zacznij od najbardziej podstawowej funkcjonalności jaką jesteś w stanie zrobić.
4. Napisz jakąś prostą funkcjonalność najprościej jak się da, bez frameworka. Zakodź sam najbardziej podstawowe elementy.

Mam wrażenie że napisałeś to samo na 4 różne sposoby i normalnie bym się zgodził (znaczy się to po prostu rady uncle boba), ale nie wiem ile można odroczyć wybór frameworka przy robieniu frontendu. Może się uda to zrobić do drugiego dnia developmentu?
Znaczy się frontend to jednak głównie UI, zazwyczaj mamy thin client i niewiele logiki niezwiązanej z interfejsem po stronie klienta. Jeśli zrobisz UI bez frameworka to potem będziesz musiał to praktycznie wszystko restrukturyzować.
Znaczy chciałbym w sumie zobaczyć jak robisz frontend wybierając biblioteki na samym końcu.

iteredi napisał(a):

Z tego co widzę już teraz to różne frameworki JS używają różnych języków. Angular używa TypeScripta, w React widzę pliki z rozszerzeniem jsx (jakieś rozszerzenie JS'a?)

W react też możesz (a nawet powinieneś) użyć typescripta. TSX / JSX to tylko małe rozszerzenie TS / JS

takiego kodu TS nie da się użyć bezpośrednio w przeglądarce - trzeba go najpierw przekształcić na czysty JS jakimś narzędziem budującym projekt (webpack?).

Racja, dlatego polecam od razu użyć gotowego webapp frameworka i mieć wszystko skonfigurowane tak żeby można przejść od razu do developmentu. Jak "odroczysz decyzje" wyboru frameworka to będziesz musiał sobie konfigurować samemu wszystkie podstawowe rzeczy takie jak właśnie np obsługa TS i routingu (które masz out of the box np w next.js i jest oparte o strukturę folderów a nie o kod).

Dlatego sugeruję zupełnie inne podejście, najpierw wybrać framework, obojętne jaki i zacząć w nim pisać aplikację możliwie separując logikę od widoków i zależności frameworkowych.
Jak się nie spodoba to zmienić framework, co jest dużym wyzwaniem ale nie na początkowym stadium projektu. Nawet jak się spodoba to sugeruję spróbować zrobić to samo w innym żeby zobaczyć czy czasem nie byłoby ci lepiej. Tego co zajmuje najwięcej czyli komponentów wizualnych i tak nie będziesz mógł za bardzo przenieść bez zmian, ale we wczesnych etapach to nie powinien być problem. Zresztą co da odroczenie decyzji o wyborze frameworka jeśli nadal nie będziemy wiedzieć nic o żadnej z alternatyw? O odroczeniu decyzji można mówić gdy znamy dobrze wszystkie możliwości.

W gruncie polecam to samo co Riddle czyli odroczenie decyzji o wyborze frameworka na później, ale zamiast pisać cokolwiek zupełnie bez frameworka i bibliotek tak jak on poleca i co moim zdaniem jest skomplikowane i mało wykonalne, to polecam traktować frameworki luźno i je zmieniać w miarę potrzeby; najlepiej jeszcze na w miarę wczesnym etapie projektu bo tak czy inaczej Twój projekt chcąc lub nie chcąc będzie miał powiązania z frameworkiem i z czasem coraz trudniej będzie wykonać taką zmianę.

iteredi napisał(a):

Z tego co widzę już teraz to różne frameworki JS używają różnych języków. Angular używa TypeScripta, w React widzę pliki z rozszerzeniem jsx (jakieś rozszerzenie JS'a?), są też frameworki które używają czystego JS'a. Takiego kodu TS nie da się użyć bezpośrednio w przeglądarce - trzeba go najpierw przekształcić na czysty JS jakimś narzędziem budującym projekt (webpack?).

Jest sobie JavaScript. I to jest punkt startowy.

Jest też JSX, który jest dodatkiem do JavaScriptu, który polega na tym, że można w JavaScript coś podobnego do HTMLa wrzucać np.

const foo = <div className="foo">cztery = {2 + 2}</div>

to jest zamieniane w trakcie transpilacji na czysty JavaScript, np.:

const foo = jsx("div", {className: 'foo', children: ["cztery =", 2 + 2]});

albo na coś innego, w zależności od ustawień (tj. nie jest aż tak ważne, na co jest zamienane, ale ważne żeby wiedzieć, że JSX to nie magia, a po prostu składnia HTMLo-podobna, która jest zamienana na wywołania jakichś konkretnych funkcji w JS. Czyli JSX to tylko cukier składniowy, inny sposób zapisu funkcji czystego JS).

Jest sobie TypeScript, który jest językiem opartym o JavaScript (dodaje do JSa statyczne typowanie).

Znajdziesz również pliki .tsx, czyli TypeScript + JSX.

Najlepiej będzie zacząć od czystego JSa, żeby wiedzieć, gdzie są granice języka (wiele osób zaczyna od TypeScriptu i potem żyją w nieświadomości, co jest czystym JSem, a co jest TypeScriptem).

No i też lepiej załapać, jak działa JS, zanim się wejdzie we framework.
Np. żeby sprawnie działać w React, powinieneś wiedzieć z JSa, jak działają domknięcia(closures), asynchroniczność, wiedzieć, jak pisać niemutowalny kod w JS itp. Bo bez tego ciągle będziesz miał błędy i będzie się wydawało, że to błędy w React, a to będą błędy wynikające z nieznajomości JS (wspominam o React, bo z tym mam najwięcej do czynienia, nie wiem czy inne frameworki są bardziej przyjazne pod tym kątem. Ale w React na pewno trzeba znać podstawy JSa, żeby napisać działający kod).

Najlepiej będzie zacząć od czystego JSa, żeby wiedzieć, gdzie są granice języka (wiele osób zaczyna od TypeScriptu i potem żyją w nieświadomości, co jest czystym JSem, a co jest TypeScriptem).

Nie zaczynałem od JS, wpadłem od razu do Angulara. Granic nauczyłem się w trakcie. Szkoda czasu.

Cyrec napisał(a):

Riddle napisał(a):

1. Nie zaczynaj projektu od wyboru frameworka ani biblioteki
2. Zostaw sobie miejsce na to żeby nie podejmować żadnych decyzji na początku, odrocz je na późniejszy etap projektu.
3. Zacznij od najbardziej podstawowej funkcjonalności jaką jesteś w stanie zrobić.
4. Napisz jakąś prostą funkcjonalność najprościej jak się da, bez frameworka. Zakodź sam najbardziej podstawowe elementy.
5. Pokaż klientowi i spytaj czy taki feature może być.
6. Powtórz jeszcze kilka razy punkt 2.
7. po kilku iteracjach będziesz wiedział miej więcej jaki rodzaj funkcjonalności będzie dochodził do Twojej aplikacji.
8. Będziesz potrzebował napisać dodatkowe elementy (logowanie, router, bezpieczeńśtwo, etc.). Teraz możesz dodać bibliotekę i framework, ale najlepiej dodaj go tak, żeby nie związać go ze swoją aplikacją za bardzo (np. korzystając z dependency inversion).

Czy mógłbyś pokazać przykład jak to by wyglądało na froncie? Nie wyobrażam sobie pisać komponentów, które będą niezależne od frameworka

Ja mówiłem o logice frontu. A widzę że skoro zaczynasz mówić o komponentach, to Ty już od razu mówisz o widoku.

Więc jeśli chodzi o widok: to, jeśli tworzysz aplikację webową, to masz tak na prawdę dwa sensowne wyjścia. Pierwszym wyjsciem byłoby napisać aplikacje ją korzystając z Vue, Reacta, Angulara (lub innych), podążając za dokumentacją, tworząc komponenty tak jak te biblioteki radzą. Powstanie w ten sposób aplikacja która ma 100,200,400,1000 komponentów które wyglądają jak komponenty typowo-vue (te z <template>), typowo Reactowe (te JSX), albo typowo Angularowe (te z adnotacjami, i template stringami, etc.). Ma to swoje wady i zalety. Zaleta jest taka, że praktycznie każdy projekt napisany w ten sposób wygląda tak samo, więc każdy kto wchodzi w taki produkt może zacząć tworzyć - przynajmniej na najniższym poziomie (czyli komponentów i stanu). Natomiast wada jest taka, że jesteśmy wtedy całkowicie przywiązani do frameworka. Nie możemy już od niego odejść, bo wymagałoby to przepisania wszystkich komponentów (czyli praktycznie napisanie aplikacji od nowa). Jesteśmy też zmuszeni korzystać tylko z bibliotek które wspierają ten framework, i kiedy framework wyda nową wersję, to raczej powinniśmy zaktualizować nasz projekt, tak żeby wspierać najnowszą wersję. Wszystkie breaking-change's musimy robić my, czasami wymaga to zmian w bardzo dużej ilości komponentów. Najgorszym przypadkiem jest kiedy wychodzi najnowsza wersja frameworka; a biblioteka z której korzystamy jej nie wspiera. Wtedy praktycznie jesteśmy w czarnej.

Ale nie znaczy to oczywiście że powinniśmy pisać "swoje frameworki" albo zaczynać z niczym, jak w vanilla-js. Biblioteki takie jak React, Vue, Angular mają bardzo dużo zalet - performance, virtual dom, niezależność od przeglądarek, wsparcie bezpieczeńśtwa, duże ekosystemy, etc. Ale niestety mają też jedną nieprzyjemną wadę - mianowicie ich dokumentacje bardzo silnie zachęcają do dodania tight-couplingu na ich interfejs (tzn. że patrząc na sam komponent można po interfejsie rozpoznać z jakiego frameworka korzysta).

Tą wadę można rozwiązać przy pomocy dependency inversion.

Znaczy to, że wszystko co chcemy zrobić z naszymi komponentami (propsy, stan, HTML, zachowanie, dzieci/parenty) należy napisać swój interfejs, taki jak się nam podoba; a potem gdzieś pod spodem "wstrzyknąć" jakiś framework - i teraz już w zasadzie nie ma znaczenia jaki. Powstanie w ten sposób aplikacja, która ma 100,200,400,1000 komponentów z własnym interfejsem, który deleguje zachowanie komponentów frameworka pod spodem. Wszystkie zmiany dot. frameworka trzeba zrobić w tym jednym miejscu, a interfejs komponentów pozostanie niezmieniony. Tylko to z kolei wymaga umiejętności dobrego projektowania software'u, warto też mieć testy automatyczne pod to (co mało osób pisze na froncie), więc nie jest to takie proste. Znaczy to też, że każdy projekt napisany w ten sposób będzie wyglądał trochę inaczej, bo każdy projekt spełnia inne potrzeby.

Więc wybór czy przywiązać się do frameworka, czy wybrać swój interfejs to jest judgement call który trzeba wykonać.

A co jeśli robisz projekt dla siebie, nie dla klienta. Po kilku miesiącach dłubania w czystym js uświadomiłeś sobie że przetwarzane dane przez aplikacje będą bardzo wrażliwe a chcesz brać za to pieniążki. Zostałbyś na czystym js bez api czy wrzucał framework z api i refaktoryzował cały kod?

mitowski napisał(a):

A co jeśli robisz projekt dla siebie, nie dla klienta. Po kilku miesiącach dłubania w czystym js uświadomiłeś sobie że przetwarzane dane przez aplikacje będą bardzo wrażliwe a chcesz brać za to pieniążki.

Szczerze mówiąc, tak osobiście, teraz jak tworzę projekty, to robię je tak samo zarówno dla klienta jak i dla siebie. Zawsze chcę wytwarzać soft bardzo szybko, i tak żeby spełniał wymagania. A najlepszy sposób żeby pracować szybko i wytwarzać soft który spełnia wymagania to nie stawiać sobie kłód pod nogi. Takimi kłodami jest: brak testów, słabe nazwy, syf, duże klasy, coupling, niepotrzebna duplikacja.

W co do Twojego pytania, to nie do końca rozumiem co to zmienia że dane są "wrażliwe"? Wszystko co jest u klienta (czyli np w przeglądarce) jest potencjalnie niebezpieczne, więc jakby...? Chyba nie rozumiem pytania.

mitowski napisał(a):

Zostałbyś na czystym js bez api czy wrzucał framework z api i refaktoryzował cały kod?

Znaczy ja nie mówiłem żeby pisać "w czystym JS". Ja mówiłem, że jeśli chcesz skorzystać z biblioteki (jak React, Vue, Angular czy jakakolwiek inna) to należy to zrobić tak, żeby nie przywiązać swojej aplikacji do tego frameworka. Korzystam z bibliotek - nie chcę pisać wszystkiego od nowa; ale nie koniecznie używam ich interfejsów - tylko zrobię sobie warstwę pośrednią pomiędzy logiką aplikacji a interfejsem biblioteki.

To może inaczej, api wykorzystujesz tylko do łączenia ze sobą aplikacji czy traktujesz to jako dodatkowy element pośredni zabezpieczający bazę przed niekontrolowanym dostępem do danych? Bo jak rozumiem wprowadzenie api wymusza korzystanie z frameworków frontendowych jak vue, react, angular?

mitowski napisał(a):

Bo jak rozumiem wprowadzenie api wymusza korzystanie z frameworków frontendowych jak vue, react, angular?

Nie rozumiem. Co masz na myśli przez api?

LukeJL napisał(a):

mitowski napisał(a):

Bo jak rozumiem wprowadzenie api wymusza korzystanie z frameworków frontendowych jak vue, react, angular?

Nie rozumiem. Co masz na myśli przez api?

Gadałem z @mitowski na priv. Ma zupełnie inny problem, niezwiązany z UI.

Ogólnie wydaję mi się że trochę za bardzo to wszystko komplikujecie (razem z autorem). Dzielicie front-end pod tysiące różnych czynników itd. Czy projekt który planujesz autorze robić jest jakimś edytorem, odtwarzaczem muzyki lub streamu lub też innym projektem o wysokim stopniu zaawansowania front-endowego?

Bo jeśli nie, to za dużo rozwodzenia się. Ciężko powiedzieć coś o "polecić jakieś źródło informacji" dot. front-endu, bo pomimo że nowe frameworki js-owe wychodzą codziennie to liczący się gracze na rynku są od wielu lat ci sami: React, Angular, Vue. A z tej trójki wystarczy wybrać to co zespół mający robić projekt zna najlepiej i z czym ma najwięcej doświadczenia. A jeśli zespół to sami twardzi backendowcy to jeszcze łatwiej bo można wybrać z tej trójki framework który najbardziej "imituje" backend czyli Angular. Jest klasowowść, są serwisy, dependency injection i inne pierdalety znane z takich .Net-ów itd.