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

1

Ż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

0
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/[...]eb/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?

0
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/[...]eb/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?

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.

0

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.

0

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.

1
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.

0

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

2

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.

1

@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
0
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łę.

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