ASP.NET + Blazer vs React/Angular/Node/Vue

0
Wibowit napisał(a):
mad_penguin napisał(a):

Ogólnie @wloochacz dobrze to opisałeś. Działa to faktycznie podobnie jak react - wyliczanie diffa DOMu odbywa się na backendzie i ten diff jest wysyłany do przeglądarki przez websocketa.

W takim razie ten virtual DOM na backendzie rozpycha sesję (DOM może sporo ważyć, zwłaszcza gdy mamy np tabelkę 20 kolumn x 1000 wierszy) i może spowodować problemy ze skalowaniem (zawartość sesji jest na tyle skomplikowana i zmienna, że trzeba trzymać ją bezpośrednio w procesie serwera).

Istotnie, sam MS wyraźnie o tym pisze i nie ukrywa, że ta technologia nie zawsze i do wszystkiego jest OK.
Poza tym, Blazor posiada 3 modele hostingowe dla swoich aplikacji:

  1. Blazor on ASP NET
  2. Blazor WebAsembly
  3. Blazor Server

Pierwszy i drugi są bardzo podobne do siebie (sam w sumie jeszcze nie do końca wszytko dokładnie rozumiem, a więc nie wypowiem się teraz).
Trzeci - to już wiadomo.
Najlepsze informacje na ten temat znalazłam u Telerika:
https://www.telerik.com/blogs[...]kdown-of-blazor-project-types

Dość powiedzieć, że w moim VS.Studio 2019 mam do wybory takie projekty:
Blazor.png

I bądź mądry co jest co ;-)

Mogę jeszcze opisać co ma być kiedyś, ale wolałbym dyskutować o tym, jak już będzie ;-)

Jak Blazor sobie z tym radzi? Np co jeśli mamy 100 aktywnych użytkowników z których każdy ogląda tabelkę 20 kolumn x 1000 wierszy i te tabelki się zmieniają np raz na sekundę dochodzi nowa pozycja w losowym miejscu?

Dokładnie to nie wiem.
MS pisze, o tu:
https://devblogs.microsoft.co[...]-0-scenarios-and-performance/
o tym problemie w ten sposób:

In our tests, a single Standard_D1_v2 instance on Azure (1 vCPU, 3.5 GB memory) could handle over 5,000 concurrent users without any degradation in latency. A Standard_D3_V2 instance (4 vCPU, 14GB memory) handled well over 20,000 concurrent clients. The main bottleneck for handling further load was available memory. Will you see this level of scale in your own app? That will depend in large part on how much additional memory your app requires per user. But for many apps, we believe this level of scale out is quite reasonable. We also plan to post additional updates on improvements in Blazor Server scalability in the weeks ahead. So stay tuned!

My mamy aplikację tego typu, tzn trade blotter z dynamicznym odświeżaniem, ale mamy problem ze skalowaniem, więc obsługujemy bardzo małą ilość aktywnych użytkowników (max kilkadziesiąt naraz). Zakładamy, że po przeniesieniu się na SPA ze stanem po stronie przeglądarki skalowalność mocno się polepszy.

Istotnie, to może być problem.
Poczekamy do maja, wtedy dowiemy się więcej.

0

Nowa prezentacja o Blazorze, jakby ktoś jeszcze nie widział. Pierwsze stabilne wydanie w maju 2020.

1
nobody01 napisał(a):

Nowa prezentacja o Blazorze, jakby ktoś jeszcze nie widział. Pierwsze stabilne wydanie w maju 2020.

Pierwsze stabilne wydanie w maju 2020r dotyczy wersji Client Side czyli tej opartej o WebAssembly.
Pierwsza stabilna wersja server side wyszła razem .NET Core 3.

0

Nowe info od Bytecode Alliance (Mozilla, Fastly, Intel, and Red Hat)

Wykonywanie WASM w .NET

https://hacks.mozilla.org/201[...]ly-from-dotnet-with-wasmtime/

0

1.5 MB na starcie to jak na obecne standardy dużo czy normalnie?
Blazor team has target of 1.5MB when Blazor WebAssembly is released at May.
https://gunnarpeipman.com/focus-on-blazor-announcements/

1

Sporawo. Reversi w Scala.js to po spakowaniu jakieś 30 KB wygenerowanego JSa:
https://github.com/scala-js/s[...]/tree/master/examples/reversi
https://github.com/scala-js/s[...]/blob/master/ci/checksizes.sh

Obstawiam też, że ściąganie tego WASM-Blazora będzie i tak krótsze niż ładowanie go. Ktoś mierzył czas uruchamiania?

1
Wibowit napisał(a):

Sporawo. Reversi w Scala.js to po spakowaniu jakieś 30 KB wygenerowanego JSa:

Mam zupełnie inne zdanie i wg mnie jest to zajefajnie akceptowalne.
Zauważ, ze Blazor to specyficzne cudo do specyficznych zastosowań.
Głównie mam tu na myśli wszelki LoB'y. które raczej działają w intra/extra netach a nie w interencie.
Pisanie np. serwisu społecznościowego, forum czy globalnego sklepu internetowego w Blazorze sensu wielkiego nie ma.
Ale pisanie wszelkich aplikacji biznesowych do użycia wewnętrznego w danej organizacji już jak najbardziej tak.

https://github.com/scala-js/s[...]/tree/master/examples/reversi
https://github.com/scala-js/s[...]/blob/master/ci/checksizes.sh

Obstawiam też, że ściąganie tego WASM-Blazora będzie i tak krótsze niż ładowanie go. Ktoś mierzył czas uruchamiania?

No offence, ale to pytanie nie ma sensu.
Czym innym będzie generowanie formularza z koszykiem, a czym innym np. gra w przeglądarce.
Poza tym, WASM z definicji ma być szybki i trudno mi uwierzyć, aby JS go dogonił.
Pierwszy przykład z brzegu:
https://www.smashingmagazine.[...]04/webassembly-speed-web-app/

0
wloochacz napisał(a):

Poza tym, WASM z definicji ma być szybki i trudno mi uwierzyć, aby JS go dogonił.

Na szczęście informatyka i programowanie to bardziej inżyniera i nauka niż religia. Więc nie wystarczy powiedzieć, że jest "tak i tak". Trzeba jeszcze to udowodnić.
Jakieś benchmark? Czy WASM jest zawsze szybszy od JS? Czy "Hello World" jest szybsze w WASM niż JS? Czy jakbym miał odpowiednik JQuery w WASM to będzie szybciej? A może odpowiednik Vue? Gdzie jest punkt w którym WASM wyprzedza JSa? Jak duży do ma być projekt. Albo jaki rodzaj projektu? Więcej pytań niż odpowiedzi.

Jak już Graal będzie kompilować bytecode Javy do WASM to nawet taki benchmark będzie niesamowicie łatwo zrobić

0

Chyba różnie z tym jest. Coś takiego znalazłem: https://takahirox.github.io/WebAssembly-benchmark/ Nie wiem, ile to jest warte @Wibowit ?

1
wloochacz napisał(a):
Wibowit napisał(a):

Obstawiam też, że ściąganie tego WASM-Blazora będzie i tak krótsze niż ładowanie go. Ktoś mierzył czas uruchamiania?

No offence, ale to pytanie nie ma sensu.

Moim zdaniem ma i to dużo. Jeśli strona ładuje się 20s, ale już po 1s widać treść, a przez 19s ładują się dodatkowe bajery to jest to dużo lepsza sytuacja niż gdy strona ładuje się przez 10s, ale dopiero po pełnym załadowaniu ekran ładowania zamienia się w treść strony.

wloochacz napisał(a):

Poza tym, WASM z definicji ma być szybki i trudno mi uwierzyć, aby JS go dogonił.
Pierwszy przykład z brzegu:
https://www.smashingmagazine.[...]04/webassembly-speed-web-app/

nobody01 napisał(a):

Chyba różnie z tym jest. Coś takiego znalazłem: https://takahirox.github.io/WebAssembly-benchmark/ Nie wiem, ile to jest warte @Wibowit ?

Takie benchmarki mają mniej więcej tyle sensu co te na https://benchmarksgame-team.p[...]marksgame/fastest/python.html

Lepsze są benchmarki zorientowane wprost na weba, np:

Dalej są trochę nieżyciowe, ale i tak są daleko bardziej sensowne niż benchmarki sekwencjonowania DNA w przeglądarce czy mierzenie wydajności operacji wektorowych w ciasnych pętlach. Przede wszystkim propozycje powyżej mierzą wydajność frameworków i bibliotek zorientowanych na szersze użycie, a nie jakichś super zoptymalizowanych JanuszLibów mających wykręcić najwyższy wynik w totalnie abstrakcyjnym benchmarku.

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