Cześć.
Czytałem niedawno, że MS w .NET Core zaleca stosować Razor Pages. Jak to się ma do innych technologii, Angularów, React itp?
Sądzicie, że będzie rosnąć zapotrzebowanie na programistów znających Razor Pages, czy Angulara to nie przebije?
0
1
A dlaczego by nie znać obu?
Wydaje mi się, że Razor Pages są bardzo intuitywne, więc raczej nie ma problemu z uczeniem się ich.
By using Angular/React with api in server side:
- you eliminate process of generating HTML in server side and you save cpu
- api produces small payload (json) and Razor (html) of a course would be much larger in size, constant full page reloads and postback round trip. so api and spa save bandwidth
api and spa could have different versioning, scaling and deployment scenariosBy using api you can support mobile app too and if you start by Razor you may need api in futurebut by using Angular/React you should be worry about clients.
client must enable javascriptclient must have modern browsersclient must have enough powerful hardwareSEO
https://stackoverflow.com/questions/46231344/asp-net-core-2-0-razor-vs-angular-react-etc
Jak na moje, to szybciej i prościej jest zrobić mniejszy projekt przy użyciu Razora niż ładować angulary reacy itd., a z bardziej skomplikowanymi rzeczami to nie wiem jak jest.
W sumie podłącze się do pytania: Czy wystawienie MVC+Razor pages jest w jakimś stopniu ograniczone względem WebAPI i na froncie np. Angulara jeżeli chodzi o jakieś "współczesne czary" na frontendzie? Czy różnicą jest jedynie na łatwości rozdzielenia pracy?
3
W wyliczance koleś zapomniał o czymś bardzo ważnym - rozmiarze stanu strony i jego wpływie na skalowalność. We frameworkach server-side stan leci do sesji użytkownika siedzącej na serwerze. We frameworkach client-side stan siedzi w przeglądarce. Jeśli stan to 100 MB to przy frameworku server-side łatwo zapchać serwer - 100 zalogowanych użytkowników daje 10 GB stanu na serwerze. W przypadku frameworku client-side te w każdej przeglądarce siedzi po 100 MB stanu, a serwer jest odciążony (w sensie nie ma zapchanego RAMu). Odciążony serwer to większa elastyczność po stronie backendu.
1
Wszystko zależy od skali problemu, wymagań itp. Gdzieś sprawdzi się single page application i renderowanie po stronie klienta, a gdzie indziej po stronie serwera. No chyba że trafisz na programistę/architekta który na wszystko ma jedno "właściwe" rozwiązanie ale takich ludzi radzę unikać bo to po prostu źli specjaliści są.
Warto znać obie technologie, chociaż nie koniecznie Razor Pages a ogólnie ASP Core MVC. RP można bo dla czego by nie ale moim zdaniem to bardziej ciekawostka. Nie podoba mi się to jak miesza się w nich model z kontrolerem, poza tym sam kontroler nie pozwala na taką swobodę jak "pełnoprawny" kontroler MVC. Osobiście wolę "tradycyjne" podejście z zastosowaniem feature slices.
Warto mieć również na oku projekt Blazor bo myślę że to jest przyszłość aplikacji webowych opartych o .Net.
0
Jeszcze odniosę się do potencjalnych wad SPA:
but by using Angular/React you should be worry about clients.
- client must enable javascript
- client must have modern browsers
- client must have enough powerful hardware
- SEO
Jak chcemy mieć dynamiczną stronę i wchodzimy w AJAXy, Comety/ WebSockety itd to i tak klient musi mieć włączony JavaScript, nowoczesną przeglądarkę, sensowny sprzęt (aczkolwiek nawet na tanich smartfonach wiele stron wykonanych w technice SPA chodzi swodobnie, trzeba tylko projektować aplikację z głową), a SEO też siada.
W kwestii SEO sądzę, że SPA oferuje nawet lepsze rozwiązanie niż przy ręcznym użyciu jQuery i tym podobnych niskopoziomowych bibliotek. Frameworki do SPA oferują routing (inna zawartość strony w zależności od URLa) oraz server side rendering, więc łącząc te dwie techniki dla botów strona wygląda jak statyczna. Przy użyciu jQuery server side rendering trzeba samemu klecić.
Jeśli chodzi o wydajność to jakikolwiek dynamizm na stronie może zajechać przeglądarki typu Internet Explorer 11 (korpo standard pod który musimy optymalizować stronę). Mieliśmy przypadek w którym zwyczajna podmiana zawartości taga w DOMie potrafiła trwać kilkadziesiąt sekund na IE11. W tym tagu była co prawda zawarta złożona i mocno ostylowana tabela z wieloma wierszami (setki, a może nawet tysiące), ale Google Chrome i Mozilla Firefox radziły sobie akceptowalnie. Stąd chcąc mieć stronę która działa szybko na IE11 musimy zrezygnować nie tylko z ciężkiego JavaScriptu, ale też z ciężkiego CSSa (albo tak jak my: pociąć podsyłane do przeglądarki HTMLe na mniejsze kawałki, by zmniejszyć freezy). Dodam jeszcze, że chodzi o aplikację legacy wykonaną w technice server-side :) Niedługo będziemy przerabiać ją pod Reacta, by hulała znacznie szybciej (bo w Reactu łatwiej przykombinować z optymalizacjami).