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

Jaka znowu awersja do nowego? Transpilacja do JSa to nie jest nowa rzecz, istnieje co najmniej te kilkanaście lat. Lista języków transpilowanych do JSa: https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js Jest na tej liście sporo języków używanych do backendu jak np Java, C#, Kotlin, Python, Haskell, Clojure itd

Do C# są rozwiązania wydane na długo przed Blazorem, np Bridge.NET

• wersja 1 na GitHubie: https://github.com/bridgedotnet/Bridge/releases/tag/v1.0.0
• kompilator on-line https://deck.net/

Niby mocną stroną Blazora ma być mocne ukierunkowanie się na WASMa, ale czy to niby jest bezdyskusyjnie zaletą? WASM wcale nie jest potrzebny do tego, by używać jednego języka na froncie i backendzie jak pokazuje lista transpilowanych języków. Abstrakcje i tak będą cieknąć, więc upychanie semantyki .NETowej do WASMa raczej będzie się okazyjnie sypać przy skomplikowanej interakcji z API przeglądarkowym.

O 18:30 naszego czasu kolejna prezentacja, tym razem o przyszłości Blazora client side:

@Wibowit: weź Ty się uspokój. Jesteś dobrym przykładem powiedzenia "uderz w stół a nożyce się odezwą". Jakiego nowego? Ano takiego że Blazor jest czymś nowym, nieważne że transpilacja JSa istnieje od dawna. Podobnie jak nowy framework JSowy będzie- o ironio- czymś nowym. MVC (framework) też kiedyś był czymś nowym, pomimo że istniały już podobne technologie. I o to na czym polega "nowe" w tym przypadku. Serio, w Twoim przypadku chyba sprawdza się to co napisałem w innym wątku- są tacy co sobie kodują w danej technologii i są zadowoleni, oraz tacy co kodują w danej technologii i nie mogą przeżyć że ktoś może to robić w innej i być zadowolonym. Ty chyba się zaliczasz do tego drugiego grona. Czasem napiszesz coś wartościowego ale w większości tematów tylko raban robisz bo przecież jak Microshit jest tematem to trzeba jechać z koksem. Koniec dyskusji z mojej strony.

Ps: Swoją drogą piszesz że to nic nowego "bo transpilacja" całkowicie pomijając inne cechy tej technologii. Zabawne...

szydlak napisał(a):

Zainstalowałem sobie, utworzyłem domyślny projekt. Fajnie to wygląda. Ciekawi mnie czy warto się tego uczyć? W sensie czy w ciągu roku, dwóch zaczną powstawać aplikacje w tym.

klikam sobie od czasu do czasu coś w blazorze (jako osobna apka, która tylko strzela requestami, a nie ta serverowo związana część na signalerze) i w sumie nie jestem pewien co masz na myśli "czy warto się tego uczyć"

ale czego? bo c# i jego środowisko znasz, więc co tak właściwie miałbyś się uczyć z Blazora? jak podpiąć funkcję pod np. przycisk? zbindować-2-way zmienną z input boxem?

routing? ukrywanie contentu dla unauthorized? wydaje mi się, że to jest 1 dzień zabawy :P

Jakby ktoś postawił server side Blazor na hostingu to niech da znać jak wygląda responsywność przy edytowaniu/klikaniu elementów. Lokalnie ten moment komunikacji z serwerem jest niezauważalny ale ciekaw jestem jak to wygląda kiedy w grę wchodzi komunikacja sieciowa na większe odległości.

Ja niestety na razie nie mam czasu ale jak ktoś nie przetestuje do weekendu to spróbuję sam coś postawić na hostingu.

Wibowit napisał(a):

Blazor to taki Google Web Toolkit (GWT) bis tyle, że teraz mamy C# zamiast Javy (główna różnica widoczna dla programisty) i kompilację do JS+WASM zamiast samego JSa (to akurat "szczegół" implementacyjny raczej). GWT miał pierwszą oficjalną wersję 13 lat temu (2006 rok).

Tak i nie.
Zapominasz o czymś, co się zwie Blazor Server (no i właśnie, uj wie jak to się zwie. Sam MS zrobił okrutny burdel w nomenklaturze).
O to mi chodzi:
https://docs.microsoft.com/pl-pl/aspnet/core/blazor/hosting-models?view=aspnetcore-3.0#blazor-server

A to po pierwsze nie jest już eksperyment, a po drugie działa zupełnie inaczej i nie jest potrzebne żadne Mono WASM i nie ma tam WebAssembly.
Ale sam kod po stronie serwera jest praktycznie identyczny jak w przypadku Blazor Client.
Żadnego babrania się w syfie (JS), żadnych ograniczeń przeglądarki.
No jak dla mnie bajka, bo ja jestem twardogłowym (strong-typed ;-)) programistą i te wszelkie cuda wianki i wiązanie krawata trzymając rękę w tyłku, jakie odchodzą na front-endzie powodują, że mam torsje.

Nie jestem w temacie dokładnie, ale jednym z powodów upadku GWT jest to, że było wzorowane zdecydowanie bardziej na desktopowych UI toolkitach niż na podejściu typowo HTMLowym. Problemem był też długi czas kompilacji, niewygodna integracja z nowymi bibliotekami JSowymi, itd

Tu jest jednak inaczej.

Mimo wszystko przez kilka lat GWT było hitem i dużo Javowych zapaleńców robiło w tym aplikacje biznesowe. Samo Google też. Na stronie http://www.gwtproject.org/ mamy:

GWT is used by many products at Google, including Google AdWords and Google Wallet. It's open source, completely free, and used by thousands of enthusiastic developers around the world.

Google Wave było oparte o GWT i jak pewnie niektórzy pamiętają, też zdechło i to bardzo szybko.

Bardzo możliwe, że Blazora spotka to samo. Najpierw ekscytacja przez kilka lat, a potem zapomnienie. Jasnowidzem (czarnowidzem?) jednak nie jestem, więc nie będę się pod tym podpisywał. Jeśli jednak miałbym obstawiać to stawiałbym na to, że za 10 lat zainteresowanie Blazorem (bądź bliżniaczymi pod względem mechaniki projektami w .NETu o ile takie będą) będzie nikłe.

Mam zupełnie inne zdanie na ten temat.
Nie każdy pisze aplikacje do lajkowania kotów (albo super-duper portali) dostępnych everywhere.
Ja np. mam bardzo konkretne potrzeby, co do których taki Blazor Server włączenie z jego ograniczeniami (a są takie) jest po prostu idealny.
Sądzę, że powstanie w nim duża ilość aplikacji biznesowych działających w intranetach/ekstranetach.

Poza tym mamy coś takiego RadZen: https://www.radzen.com/
Co dla klikaczy (chodzi tak naprawdę o szybkie tworzenie frontu do bazy danych, albo i może prototypu większego projektu) wydaje się mega cukierkowate.

I fakt Blazor Client (czyli oparty o WebAssembly i całkowicie wykonywany w przeglądarce) aktualnie nadaje się tylko do eksperymentów.

Webowe UI w GWT też może bez problemu komunikować się z serwerem. Jest nawet szybkie w klepaniu GWT RPC jeśli nie zamierzasz udostępniać RESTowego API: Should I build a REST backend for GWT application

Wibowit napisał(a):

Webowe UI w GWT też może bez problemu komunikować się z serwerem.

OK, ale zupełnie nie o to chodzi...
Jednym zdaniem: Blazor Server to aplikacja ASP NET Razor Pages uruchamiana na serwerze w całości dla każdego klienta.

Ta komunikacja z serwerem, to de-facto przesyłanie komendy i różnicowe kawałki DOM z serwera do klienta.
Przesyłane dane są binarne i domyślnie kompresowane.
Po stronie serwera odpowiada za to SignalR, a po stronie klienta jest to JS kod na WebSocket, ale co do zasady - to nie jest komunikacja z API!

Ona w tym modelu jest po prostu niepotrzebna, ponieważ kod jakiejkolwiek logiki strony jest de-facto na serwerze (i dlatego możemy sobie pisać np. w C#, a nie w JS), a serwer może sobie odpytać usługę (serwis, mikro-serwis, bazę danych czy cokolwiek innego) o dane jak chce - również in-process.

Dlatego potrzebne jest niezawodne połączenie z serwem, ponieważ bez niego klient leży i kwiczy.

Jest nawet szybkie w klepaniu GWT RPC jeśli nie zamierzasz udostępniać RESTowego API: Should I build a REST backend for GWT application

Uhm... jednak nie rozumiesz jak to działa, a mimo to wieszczysz i krytykujesz.
A różnice pomiędzy GWT a Blazor Server są naprawdę istotne i opierają się na zupełnie innych założeniach.

@wloochacz

I fakt Blazor Client (czyli oparty o WebAssembly i całkowicie wykonywany w przeglądarce) aktualnie nadaje się tylko do eksperymentów.

Dlaczego tak sądzisz?

Wydaje mi się, że relatywnie proste aplikacje (get data from request, render table, submit something) można spokojnie pisać

Problemem może być tylko size dllek

WeiXiao napisał(a):

@wloochacz

I fakt Blazor Client (czyli oparty o WebAssembly i całkowicie wykonywany w przeglądarce) aktualnie nadaje się tylko do eksperymentów.

Dlaczego tak sądzisz?

Ponieważ sam MS tak twierdzi i zastrzega, że do maja przyszłego roku sporo może się tutaj zmienić.
To jest technology preview, a nie nawet beta cy RC.

Wydaje mi się, że relatywnie proste aplikacje (get data from request, render table, submit something) można spokojnie pisać
Problemem może być tylko size dllek

Mam swoje doświadczenia na bazie których, nie odważyłbym się dać rozwiązania opartego na tak niestabilnej platformie.
A poza tym... to po prostu działa słabo, a ekosystem praktycznie nie istnieje.
Ja wiem, że DevEx, Telelrik czy Syncfusion działają,, ale wystarczy zobaczyć jak to działa i jakie są komentarze (ja do prawie dwóch dekad z DevEx za pan brat, a więc tam głownie zaglądam).
No jest po prostu za wcześnie.

Ale można np. używać komponentów JS czy tych dla ASP NET Core w Blazor Server.
Trochę to pokręcone, ale możliwe.

Że też ja zapomniałem o tym wątku. Niedawno pojawiła się u mnie w pracy potrzeba wewnętrznej aplikacji ułatwiającej developerom debugowanie problemów na produkcji. Chodziło o to aby na podstawie szczątkowych informacji od użytkowników wyciągnąć interesujące nas dane z systemu. Po prostu zautomatyzowanie tego co każdy developer musiał robić manualnie do tej pory. Jako że zbliżał się termin mojego odejścia i nie było sensu zabierania się za większe prace to wyciągnąłem zadanie z backloga i zabrałem się do pracy właśnie przy użyciu Blazor Server. Dla czego? Ponieważ normalnie używamy stacku React.js + backend w .Net. Oczywiście do prostszej wewnętrznej aplikacji nie było sensu pisania UI w React i oddzielnie API, a jednocześnie ważne było aby logika wykonywała się po stronie serwera jako że domyślnie musi łączyć się z bazami danych na produkcji.

Zajęło mi to kilka dni i muszę przyznać że naprawdę mi się podobało. Efekt końcowy zadowolił innych w zespole, a przy okazji była to dobra okazja na przetestowanie nowej technologii. Napotkałem dwa dosyć ciekawe problemy, i okazało się że "it's not a bug, it's a feature". Moim zdaniem jest to sprawa dyskusyjna. Nie chce mi się tego tutaj dokładnie opisywać jeszcze raz, zainteresowanych odsyłam do tego co napisałem na ich GitHub'ie:

https://github.com/aspnet/AspNetCore/issues/14507
https://github.com/aspnet/AspNetCore/issues/14704

wloochacz napisał(a):

Wibowit napisał(a):

Webowe UI w GWT też może bez problemu komunikować się z serwerem.

OK, ale zupełnie nie o to chodzi...
Jednym zdaniem: Blazor Server to aplikacja ASP NET Razor Pages uruchamiana na serwerze w całości dla każdego klienta.

Ta komunikacja z serwerem, to de-facto przesyłanie komendy i różnicowe kawałki DOM z serwera do klienta.
Przesyłane dane są binarne i domyślnie kompresowane.
Po stronie serwera odpowiada za to SignalR, a po stronie klienta jest to JS kod na WebSocket, ale co do zasady - to nie jest komunikacja z API!

Ach to tak. A tą różnicę to Blazor sam oblicza (a'la virtual DOM reconcilliation z Reacta) czy trzeba samemu zdecydować co odświeżyć? To co napisałeś brzmi trochę jak zasada działania https://www.liftweb.net/

https://github.com/fmpwizard/lift_25_samples/blob/master/src/main/scala/net/liftweb/example/snippet/Ajax.scala

  def buttonClick = {
    import js.JE._

    "* [onclick]" #> SHtml.ajaxCall(ValById("the_input"),
      s => SetHtml("messages", <i>Text box is
        {s}
      </i>))
  }

Pod onClick na elemencie HTMLowym jest podpinany handler odpalany na serwerze, który do klienta wysyła SetHtml (czyli wstawkę JSową), która jest potem odpalana z powrotem na tym kliencie. Średniawy mechanizm, ale może podobny do Blazorowego?

Wibowit napisał(a):

wloochacz napisał(a):

Wibowit napisał(a):

Webowe UI w GWT też może bez problemu komunikować się z serwerem.

OK, ale zupełnie nie o to chodzi...
Jednym zdaniem: Blazor Server to aplikacja ASP NET Razor Pages uruchamiana na serwerze w całości dla każdego klienta.

Ta komunikacja z serwerem, to de-facto przesyłanie komendy i różnicowe kawałki DOM z serwera do klienta.
Przesyłane dane są binarne i domyślnie kompresowane.
Po stronie serwera odpowiada za to SignalR, a po stronie klienta jest to JS kod na WebSocket, ale co do zasady - to nie jest komunikacja z API!

Ach to tak. A tą różnicę to Blazor sam oblicza (a'la virtual DOM reconcilliation z Reacta) czy trzeba samemu zdecydować co odświeżyć?

Jestem za cienki, aby w pełni świadomie odpowiedzieć na to pytanie :)
Ale z tego co wiem, czytałem, widziałem i ciutkę testowałem, to jest to całkowicie automatyczne i transparentne dla programisty.

To co napisałeś brzmi trochę jak zasada działania https://www.liftweb.net/

https://github.com/fmpwizard/lift_25_samples/blob/master/src/main/scala/net/liftweb/example/snippet/Ajax.scala

Kopiuj

  def buttonClick = {
    import js.JE._

    "* [onclick]" #> SHtml.ajaxCall(ValById("the_input"),
      s => SetHtml("messages", <i>Text box is
        {s}
      </i>))
  }

Pod onClick na elemencie HTMLowym jest podpinany handler odpalany na serwerze, który do klienta wysyła SetHtml (czyli wstawkę JSową), która jest potem odpalana z powrotem na tym kliencie. Średniawy mechanizm, ale może podobny do Blazorowego?

W Blazor Server nic takiego się nie robi, robi to (że tak powiem) framework z automatu.
Żadnych zdarzeń, żadnej magii w stylu ajaxCall czy SetHml - po prosty klepiemy templatkę i piszemy kod w C#, bindując to wszystko w komponencie Razor.
A wygląda to jak poniżej, gdzie jest to wszystko co trzeba aby OnClick zadziałał (dodał wartość) i aby widok się zmienił i odświeżył na kliencie.

@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

PS.
Panowie mi już odpuszczą, bo ze mnie żaden spec z Blazor'a, .NETa czy C#.
Ja mam potrzebę zrobienia pewnej apki, co do której Blazor wydaje się idealny.
Dlatego zbieram sobie, że tak powiem, stos technologiczny.
I ostatnie kilka dni spędziłem na czytaniu wszystkiego, aby dokładnie zrozumieć co to jest ten Blazor i jak to (mniej więcej) działa.

Pamiętajcie proszę, że Microsoft namieszał trochę teraz.
Kiedyś mówiąc Blazor był tylko jeden, działający w przeglądarce, webassembly itd... Teraz stworzyli produkt który działa po stronie serwera... i nazwali go Blazor server side. Nazwa podobna, ale podobna technologia istniała od dawna, w starym MVC jako Razor. Generowanie stron po stronie serwera to nic nowego. Owszem, ten framework pewnie coś tam wnosi, ale nie ma się nijak do Blazora działającego na WebAssembly.

Jak dla mnie server side dużo wnosi - wrażenie z klepania frontu (pomijając słabo rozwinięte na ten moment narzędzia etc) są podobne, jak w przypadku typowego SPA (bez jakichś explicite ajaxCalli jak w przykładzie Wibowita), a mogę sobie w swoich frontowych komponentach wywoływać prosto metody z logiki biznesowej bez dodatkowej warstwy webapi. 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.

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). 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? 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.

Nie wiem, bardzo możliwe, że będzie problem :)

Wspanialy jest ten wasz entuzjazm Blazorowy. Cos jak GWT lata temu jak wspomnial @Wibowit.
Nie dostrzegacie tylko jednego drobnego problemu,ktory juz na starcie powoduje, ze Blazor traci na rzecz Vue/Angulara/Reacta.
Jest on spiety z .NET. Teraz chcialbym zobaczyc jak ktos piszacy w Pythonie/Django, Go, Javie, PHP, Rust czy jakimkolwiek innym jezyku biegnie po Blazora zeby korzystac z jego mozliwosci.
Tutaj kazdy JS ma kolosalna przewage - mozna go podpiac do dowolnego backendu.
Nikt nie wybierze .NET bo ten oferuje Blazora. Za duze koszta gdy w projekcie/firmie mamy ludzi od innego zestawu zabawek.
Rowniez nikt rozsadnie myslacy nie dobierze technologii nie pasujacej do danej domeny, bo MS wypuscil Blazora.
Takze cala zabawa zaczyna sie, i konczy w zamknietym swiecie .NET.
Czyli sa duze szanse, ze projekt nigdy nie ujrzy finalnej wersji, i stanie sie eksperymentem. Lub podzieli los innych podobnych rozwiazan.

@axde:

Raczej to jest trochę inaczej

Pod fundamentami **Blazora **po stronie klienta stoi WebAssembly, a Blazor to implementacja wsparcia dla WebAssembly w .NET

Python, Java itd. będą miały swoje implementacje, które również będą bazowały na WebAssembly, za którym to stoi W3C oraz Mozilla, Microsoft, Google, Apple (major browser vendors).

The World Wide Web Consortium (W3C) maintains the standard with contributions from Mozilla, Microsoft, Google, and Apple.

https://en.wikipedia.org/wiki/WebAssembly

WebAssembly ma duży wpływ na całą platformę web - dostarcza sposób na uruchomienie kodu napisanego w wielu różnych językach w przeglądarce z szybkością bliską natywnym rozwiązaniom, co wcześniej nie było możliwe do osiągnięcia.

https://developer.mozilla.org/pl/docs/WebAssembly

Edit:

https://github.com/mbasso/awesome-wasm#web-frameworks-libraries

asm-dom - A minimal WebAssembly virtual DOM to build C++ SPA
Blazor - Microsoft's web UI framework using C#/Razor and HTML, running client-side via WebAssembly
Yew - Rust framework for making client web apps
Perspective - Streaming pivot visualization via WebAssembly
go-vdom-wasm - Webassembly VDOM to create web application using Golang(experimental)
seed - A Rust framework for creating web apps
Vugu - A modern UI library for Go+WebAssembly

WeiXiao napisał(a):

@axde:
Python, Java itd. będą miały swoje implementacje, które również będą bazowały na WebAssembly, za którym to stoi W3C oraz Mozilla, Microsoft, Google, Apple (major browser vendors).

Java na frontendzie jest od kilkunastu lat i nadal tam żyje dzięki Vaadinowi: https://en.wikipedia.org/wiki/Vaadin

Vaadin Platform (previously Vaadin Framework) allows the implementation of HTML5 web user interfaces using the Java Programming Language.

WASM wiele tutaj nie zmienia. Wielu frontendowców robi przesadnie ociężałe stronki nie dlatego, że Google Chrome wolno wykonuje JavaScript tylko dlatego, że ich nie obchodzi, że stronki zamulają. Podobnie by było gdyby pisali w C#, bo w C# też spokojnie można zrobić ociężałą kobyłę.

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/a-breakdown-of-blazor-project-types

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

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.com/aspnet/blazor-server-in-net-core-3-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.

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

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.

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

Wykonywanie WASM w .NET

https://hacks.mozilla.org/2019/12/using-webassembly-from-dotnet-with-wasmtime/

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/

Sporawo. Reversi w Scala.js to po spakowaniu jakieś 30 KB wygenerowanego JSa:
https://github.com/scala-js/scala-js/tree/master/examples/reversi
https://github.com/scala-js/scala-js/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?

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/scala-js/tree/master/examples/reversi
https://github.com/scala-js/scala-js/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.com/2019/04/webassembly-speed-web-app/

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ć

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

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.com/2019/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.pages.debian.net/benchmarksgame/fastest/python.html

Lepsze są benchmarki zorientowane wprost na weba, np:

• backendowe: https://www.techempower.com/benchmarks/
• frontendowe: https://github.com/krausest/js-framework-benchmark

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.