W czym zrobić frontend dla backendu .NET Core?

Dzień dobry wszystkim!

Ma pewną potrzebę, gdzie aplikacja musi być dostępna gdziekolwiek, a wiec rozwiązania webowe.
Jest to aplikacja typu LoB (line of business - aplikacje biznesowe do wewnętrznego użytku firmy) i co do zasady nie będzie serwowana przez Internet, aczkolwiek nie należy tego wykluczyć.
Projekt w tej chwili jest totalnie green-field i mogę sobie pozwolić na robienie czegoś zupełnie nowego bez ograniczeń, ale musi być to stabilna i pewna droga rozwoju/utrzymania.

Na pierwszy ogień idzie aplikacja typu "panel operatorski"; włącza się to "cudo" i ma działać non-stop.
Musi być być odporna na pracę offline; nie tyle chodzi o możliwość pracy offline, co pewną i stabilną obsługę utraty/odzyskania połączenia. Innymi słowy, jak sieć (lub serwer) pada, to aplikacja ma o tym elegancko informować, ale nie może się "wysypać". Żaden reload/refresh inicjowany przez użytkownika nie wchodzi w grę.

Aplikacja oczywiście ofertuje określone przypadki użycia dla użytkowników (wprowadzają i podpatrują dane), ale równocześnie jest dashbordem który musi pracować w czasie rzeczywistym (lub do niego zbliżonym) - a więc reaguje na powiadomienia otrzymane z serwera (brokera).
Reaktywność tej aplikacji (i całego systemu) jest kluczowa.
W ogóle nacisk jest tu położony na logikę biznesową, a nie na super-fancy web-app. Oczywiście ma być schludnie, działać szybko i wyglądać na drogie

Podkreślam, że cały backend będzie tworzony wyłącznie w .NET Core i z radością wykorzystałbym możliwości, jakie oferuje ta technologia w zakresie Web/WASM (Blazor).
No ale, są ale...

Mój zespół (zespolik ) jest podzielony; jeden za Angularem, drugi za Blazorem a ja się trochę waham...
I to też jest argument; to nie korpo, a wiec idealnie by było, aby każdy orientował się w każdym aspekcie używanych technologii - raczej nie będę miał dedykowanego zespołu do frontend.

Za Angularem przemawia to, że jakieś 40% jest już zrobione - tylko dla mnie to też nie jest argument, ponieważ dokładnie wiemy co chcemy osiągnąć.
Jest pewny, znany i działa.
Ale on ma masę funkcyjności/metodyk, które nie są mi do niczego potrzebne.
I nie mam na myśli tego że twardo trzyma się reguł i krzywa wejścia jest spora, to nie jest problem.
Ja w życiu nie będę robił czegoś na kształt portalu/strony webowej.
Nie podoba mi się ten cały web-syf i naprawdę mi to nie leży

Druga opcja to Blazor (albo Razor Pages a może MVC?), może potem i MAUI - nie wiadomo.
Czy ten Blazor będzie WASM, Server czy Hybrid - to w sumie teraz bez znaczenia.

Ale podoba mi się idea pisania tego wszystkiego w jednej technologii, środowisku i języku.
Uważam, że to bardzo wygodne i może oferować ciekawe możliwości.

Gdybym miał pewność, że Blazor będzie rozwijany przez następne 5 lat to nie byłoby pytania.
Ale nie mam jej...

Zatem pytanie do Was - co byście wybrali na moim miejscu?
I dlaczego?

Tylko Angular, Blazor jest w opór mniej przyjemny i mniej dojrzały, ale to moja opinia.

Ja bym szedl w Blazora i PWA. PWA Plusy to jedna technologia która znam. Wydaje mi się że za dużo MS wsadzil w Blazoro zeby go teraz wyrzucić do koszyka. W .net 8 idzie możliwość dowolnego sterowania co ma być serwer a co ma.byc wasm. Przeciw Angularowi to mam że go nie znam i js tez nie. Jak dyskutowałem z ludźmi od Js w czym, to znaczna większość mówi że lepij Reacta.

Mi się przyjemnie robiło w Razor Pages, ale jestem gościem, który w swoim życiu jeden komponent stworzył w Angularze i na tym się skończyła moja przygoda

Angular. W razie problemów szybko znajdziesz rozwiązanie w necie. Łatwiej znaleźć ludzi którzy ogarniają Angulara. Choć sam niespecjalnie go lubię.

Tak jak @kzkzg napisał, z tej dwójki wybrałbym Angulara, chociaż osobiście optowałbym za Reactem, ale to moja preferencja. Patrzyłbym nad to jak łatwo znaleźć ludzi w razie czego oraz jakie jest wsparcie społeczności, aby nie siedzieć nie wiadomo ile nad jakimś problemem, tylko szybko znaleźć odpowiedź lub pomoc.

Niestety nie mogę porównać Angulara i Blazor-a, z samego Angulara zrobiłem krótkie szkolenie wprowadzające max 10h. W blazorze mam napisane dwie aplikację (jedną do celów prywatnych, drugą POCo). Dla mnie kluczowe była kwestia nauki type scriptu, ciężko się specjalizować w dwóch językach, dlatego wybór padł na blazor-a. Angular z ilością boilerplate też nie przypadł mi do gustu, na plus Angulara na pewno jest debugowanie i wprowadzanie zmian, bo HotReload z Visual Studio raz działa, raz nie (ale może w końcu to poprawią).

Jeżeli blazor to na pewno wybrałbym do tego jedną z bibliotek typu Radzen\DevExpress\SyncFusion. Ja korzystam z Radzen-a, jest darmowy i piszę się w nim naprawdę przyjemnie (drugi projekt w nim robiłem). W drugim projekcie mam 19 linijek js :).

wloochacz napisał(a):

Gdybym miał pewność, że Blazor będzie rozwijany przez następne 5 lat to nie byłoby pytania.
Ale nie mam jej...

Bo w przypdaku Angulara jest taka pewność... Google wcale nie ubił wersji 1 (AngularJS) tak po prostu :) .
Niestety w przypadku frameworków frontendowych nigdy nie masz takiej pewności.

A może Flutter? Uwolnisz się od JS całkowicie. Od CSS też. Tylko backend musisz wystawić resta

W mojej opinii to pytanie przypomina troche pytanie
"Musze przetransportować ładunek w formie sypkiej(informacja o wsparciu offline) jaki rodzaj transportu polecacie"

Czy Angular(albo inne narzędzie z świętej trójcy(vue,React)) czy Blazor maja swoje plusy i minusy.
W blazor jeszcze jest wybór na Server-side, client-side no i hybryda.

Osobiście wybrał bym narzędzie które lepiej znam. Gdy znam wiecej niż jedno narzędzie to wybrał bym to które lepiej się nadaje dla danego problemu (przecież ciężko się wspina w płetwach).
Jeżeli nie znam żadnego z wybranych narzędzi pozwoliłbym zdecydować tym którzy lepiej znają się w temacie.

Tak gdybając to do większego projektu wybrał bym coś z świętej trójcy.
Gdy miałby to być PoC lub mała aplikacja wybrał bym blazor aby nie angażować zespołu frontowego.

Jako że znam parę lat angulara to wszystko tylko nie angular. Fajny do prostych rzeczy, ale jak tylko chcesz zrobić coś nietypowego lub działającego szybko to odkrywasz ile jest w nim bugów i ile się trzeba napracować i robić hacków żeby uzyskać przyzwoity performance, czasem wyłączając mechanizmy które sprawiają że angular jest angularem i na przykład wykrywaniem zmian ręcznie. Miałem taki tydzień grzebiąc w bebechach angulara że codziennie odkrywałem nowego buga (wszystkie już zgłoszone i wiszą nawet po kilka lat).
Solid.js wygląda solidnie - taki react na sterydach

Co prawda nie mam w tym jeszcze żadnego doświadczenia ale jest u mnie na szczycie rzeczy do nauczenia. Podoba mi się idea kompilowania kodu i nie renderowania komponentów od zera po tysiąc razy ani robienia zbędnej pracy i porównywania różnic z jakimś "virtual dom"

Jak już iść w te nowomodne kompilowane frameworki to jednak svelte jest bardziej dojrzały

To co opisujesz, to jakaś prosta stronka. Wybór "technologii" nie ma znaczenia. Ja patrzyłbym na:

• czego chce zespół
• co ma lepszą krzywą nauki (co z tego że coś jest "fajniejsze", jak trzeba poświęcic dodatkowy tydzień, żeby projekt założyć)
• dostępność wsparcia w sieci (SO, fora)
• dostępność ludzi - jeżeli to kiedyś się rozrośnie, nie chcesz szukać ludzi do jakiegoś niszowego frameworku

I z mojego punktu widzenia (pracuję w zespole głównie backendowym) - nie mam problemu z tym, że na backendzie zaczniemy próbować jakichś nowinek, użyjemy w jakimś mikro serwisie innego frameworku, języka. Na frontendzie (gdzie jesteśmy w podobnej sytuacji jak ty) - jedziemy ścieżką, która ma najmniejsze ryzyko. Tutaj dochodzi plus korpo, jeżeli faktycznie gdzieś polegniemy, to będziemy krzyczeć "pomoc" i o ile do Angulara znajdziemy od groma ludzi, to do różnorakich wynalazków dla ludzi w rurkach już nie.

Jeśli chodzi o hostowanie, to przemyśl Azure. Daje Ci dużo na dzień dobry, chociażby informacje o tym, że apka padła.
Co do Angular vs Blazor...
Masz 40% zrobione w angularze. To niejako powinno dać Ci odpowiedź.

Jeśli to byłby nowy projekt i nie będzie dedykowanego frontu i front nie musi być jakiś ładny, to wtedy wybrałbym Blazor, bo sam go lubię.
ALE. Musisz mieć na uwadze to, że jeśli za 6 - 12 miesięcy przyjdzie ktoś na front, to niczego nie zrobi (bo pewnie nie będzie znał Blazor) i albo ktoś z BE będzie się musiał dokształcać z CSSów i tych innych pierdół, albo przepiszecie front.

Niestety Blazor wciąż jest nowinką i nie jest mocno używany, zwłaszcza przez zagorzałych frontów, którzy już ogarnęli angulara, vue, czy reacta.