Blazor - kilka pytań

0

Witam,
Ostatnio zainteresowałem się nowym dzieckiem microsoftu, który ma walczyć zapewne z frameworkami frontendowymi - Blazor.
W związku z tym chciałbym go wykorzystać w większym projekcie , który mam zamiar zrobić.
Dlatego chciałbym prosić osoby, które z niego korzystają o opinie, czy warto?
Jest przyjemniejszy w użyciu niż frameworki Js i Ts?

Dzięki za podzielenie się wszelkimi doświadczeniami :)

0

Nie piszę w C#, ale ogólnie to jest pisanie w C#, a nie w JSie... Potem ten kod jest kompilowany do WASM, więc nie porównywałbym tego w żaden sposób z JS. To jest tak, że jak nie lubisz JSa itp. tak nie musisz go tykać, po prostu piszesz kod klienta także w C#. Podobne jest to do Phoenix Live View - też piszesz w języku serwera, tyle że w wypadku frameworka Elixira tak naprawdę to zawsze jest "tylko" kod serwera, który pod wpływem eventów ze strony klienta (lecą sobie websocketem Phoenixa etc.) robi render na nowo. Blazor to w pełni kliencki kod.

W skrócie: Blazor to rewelacyjna sprawa, bo można być full stack i pisać tylko w C#.

2

Ogólnie mam całkiem dobre doświadczenia. Największym minusem jest to, że jest to nowa technologia i mało jest o tym artykułów/tutoriali. Przy nietypowym problemie zostajesz sam, więc przygotuj się na kombinowanie a nie na czytanie forum. Z pozytywów to piszesz frontend w c#, więc po przekazaniu modelu z API ze strony serwera, przetwarzasz go stronie przegladarki i masz pełną kompatybilność. Dodatkowo łatwe bindowanie danych do htmla. Bądź też na bieżąco ze zmianami, bo co wersja to sporo się zmienia https://devblogs.microsoft.com/aspnet/

0

Blazor ma dwa tryby:

  • Blazor WebAssembly - działa w przeglądarce, aktualnie w wersji poglądowej (oficjalnie jeszcze niewspieranej)
  • Blazor Server - działa na serwerze, każda interakcja użytkownika z apką to żądanie do serwera, ten tryb już jest oficjalnie wspierany

Źródło: https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-3.1

Różnice są ogólnie spore, więc trzeba zwrócić uwagę na tryb działania Blazora:

The Blazor Server hosting model offers several benefits:

  • Download size is significantly smaller than a Blazor WebAssembly app, and the app loads much faster.
  • The app takes full advantage of server capabilities, including use of any .NET Core compatible APIs.
  • .NET Core on the server is used to run the app, so existing .NET tooling, such as debugging, works as expected.
  • Thin clients are supported. For example, Blazor Server apps work with browsers that don't support WebAssembly and on resource-constrained devices.
  • The app's .NET/C# code base, including the app's component code, isn't served to clients.

There are downsides to Blazor Server hosting:

  • Higher latency usually exists. Every user interaction involves a network hop.
  • There's no offline support. If the client connection fails, the app stops working.
  • Scalability is challenging for apps with many users. The server must manage multiple client connections and handle client state.
  • An ASP.NET Core server is required to serve the app. Serverless deployment scenarios aren't possible (for example, serving the app from a CDN).
0
Pipes napisał(a):

/ciach/

W skrócie: Blazor to rewelacyjna sprawa, bo można być full stack i pisać tylko w C#.

W skrócie to napisałeś sporo niecałej prawdy i dlatego mocno sugeruje zapoznanie się z artykułem modele hostingowe ASP.NET Core Blazor

1

[Client side]

Jeżeli chcesz się nauczyć lub pobawić to jasne, jest sens, ale jeżeli chcesz napisać coś na proda, to raczej nie, jeszcze.

Blazor działa, nawet fajnie się piszę, ale tooling jest średni, a dodatkowo brak dostępu do DOMa (chociaż to bardziej problem WASMa niż Blazora), brak hot reloada powodują że development jest męczący.

Duże rozmiary dllek (ma być ogarnięte w przyszłości) też nie pomagają.

IIRC to Blazor jest częścią czegoś większego związanego z rozwiązaniami cross-platform.

0
WeiXiao napisał(a):

/ciach/

Duże rozmiary dllek (ma być ogarnięte w przyszłości) też nie pomagają.

Mamy nowe info w tej sprawie:
*[...] Using the precompressed files, a published Blazor WebAssembly is now 1.8MB, down from 2MB in the previous preview. A **minimal *app without Bootstrap CSS reduces to 1.6MB.
Sekcja "Brotli precompression" w artykule "Blazor WebAssembly 3.2.0 Preview 4 release now available"

IIRC to Blazor jest częścią czegoś większego związanego z rozwiązaniami cross-platform.

Tu też są info: Announcing Experimental Mobile Blazor Bindings February update

0

Podczas odpowiadania w innym wątku zorientowałem się, że na https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html są wyniki dla blazor-wasm, więc skopiuję tutaj informacje (bo bardziej pasują do tego tematu):

  • blazor-wasm-v3.2.0-preview4.20210.8-keyed jest średnio 9x wolniejszy od vanilla.js, startuje ponad 13x dłużej i zabiera prawie 2.5x więcej pamięci (ogólnie jest najwolniejszy, nawet rozbudowane JSowe frameworki są znacznie szybsze)
  • implementacje benchmarka dla różnych języków i frameworków są tutaj https://github.com/krausest/js-framework-benchmark/tree/master/frameworks/keyed
  • p.s. Rustowa implementacja (skompilowana do WebAssembly) jest pod nazwą wasm-bindgen (jest leciutko wolniejsza od vanilla.js)
0

@Wibowit:

Ciekawe z czego wynika ta różnica względem Rusta, no chyba code gen ssie na ten moment?

startuje ponad 13x dłużej

co startuje 13 razy dłużej?

0

Ciekawe z czego wynika ta różnica względem Rusta, no chyba code gen ssie na ten moment?

Blazor ma dość karkołomną architekturę. Wersja Rustowa to praktycznie vanilla.js przepisana do Rusta, podczas gdy Blazor jest jakimś pogmatwanym Reactoniewiadomoczym, gdzie dane latają między WASMem, a JSem (tak przynajmniej mi się wydaje, jak o tym czytam):
blazor-architecture.jpg

co startuje 13 razy dłużej?

"slowdown geometric mean" w "Startup metrics (lighthouse with mobile simulation)" dla Blazora to 14.31. Nie wiem co to dokładnie oznacza, ale:

  • spowolnienie dla "script bootup time - the total ms required to parse/compile/evaluate all the page's scripts" to 64.58x względem najszybszego rozwiązania
  • "total kilobyte weight - network transfer cost (post-compression) of all the resources loaded into the page" to 33.73x więcej niż najlżejsze rozwiązanie

Gdyby ktoś chciał sprawdzić jakość wypluwanego kodu przez Blazora to może niech podmieni pliki .wasm w https://github.com/takahirox/WebAssembly-benchmark na Blazorowe i odpali?

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