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

Odpowiedz Nowy wątek
2018-05-17 13:14
Wesoły Ogrodnik
0

Czy Blazor ma szanse konkurować z JS frameworkami?

Blazor:
A component model for building composable UI
Routing
Layouts
Forms and validation
Dependency injection
JavaScript interop
Live reloading in the browser during development
Server-side rendering
Full .NET debugging both in browsers and in the IDE
Rich IntelliSense and tooling
Ability to run on older (non-WebAssembly) browsers via asm.js
Publishing and app size trimming

https://learn-blazor.com/getting-started/what-is-blazor/
http://www.talkingdotnet.com/[...]sing-blazor-and-asp-net-core/

Pozostało 580 znaków

2019-10-15 17:04
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?


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit, 2019-10-15 17:04

Pozostało 580 znaków

2019-10-15 19:26
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.

Pozostało 580 znaków

2019-10-16 11:07
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.


edytowany 1x, ostatnio: AreQrm, 2019-10-16 17:46
Blazor a nie Blazer; Blazer to Chevrolet (samochód) a Blaser to producent broni palnej, bardzo dobrej zresztą ;-) - wloochacz 2019-10-16 16:19
Dzięki, edytowałem :-) - AreQrm 2019-10-16 17:47
To jeszcze może warto edytować to: "podobna technologia istniała od dawna, w starym MVC jako Razor"; to nie nie są podobne technologie, bo co prawda Blazor Server wykorzystuje składnię Razor Pages, ale całość działa zupełnie inaczej niż ASP NET MVC. Dlatego też MS nazywa to teraz ASP NET Core. No, bałagan z nazewnictwem mają okrutny... - wloochacz 2019-10-16 21:19

Pozostało 580 znaków

2019-10-16 11:48
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.

edytowany 1x, ostatnio: mad_penguin, 2019-10-16 11:52

Pozostało 580 znaków

2019-10-16 12:09
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.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit, 2019-10-16 12:14
jeżeli masz tabelkę 1000 wierszy to już to samo z siebie krzyczy, że coś tu jest nie tak :D - WeiXiao 2019-10-16 14:39
Zależy jakie masz wymagania biznesowe. Trejderzy mają nadziubziane masę informacji na ekranie, a nawet nieduży lag spowodowany zapytaniami do serwera może być dla nich uciążliwy. - Wibowit 2019-10-16 15:26
Chyba nie sądzisz, że jeżeli to rozwiązanie nie będzie Trading™ Ready, to będzie to wielkim problemem - WeiXiao 2019-10-16 15:41
Jak już napisałem - zależy do czego używasz. W sumie nasze wymagania są dość specyficzne. Ale i tak DOMy się rozrastają, byle stronka jest masakrycznie skomplikowana pod spodem. Pożyjemy, zobaczymy co z tego virtual DOMa po stronie serwera wyjdzie, o ile takie coś rzeczywiście jest w Blazorze zaimplementowane. - Wibowit 2019-10-16 16:09

Pozostało 580 znaków

2019-10-16 12:15
0

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

Pozostało 580 znaków

2019-10-16 15:59
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.

Pozostało 580 znaków

2019-10-16 16:02
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
edytowany 13x, ostatnio: WeiXiao, 2019-10-16 16:25

Pozostało 580 znaków

2019-10-16 16:26
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łę.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit, 2019-10-16 16:27
Pokaż pozostałe 4 komentarze
@Wibowit: nie chodzi o to? "Vaadin Flow is our next-generation Java web framework. It keeps the philosophy of previous versions of the framework: Implement UIs with Java. Vaadin Flow handles server-browser communication, routing, data binding, validation, and everything else. As before, Vaadin Flow runs on the JVM, giving you access to all the tools, languages, and libraries you love. Unlike before, Flow doesn't use GWT for the client side UI components. Instead, you get direct access to the DOM so you can extend or integrate components without added build steps." - WeiXiao 2019-10-16 16:49
Pewnie tak, wychodzi na to, że wywalili GWT. We wcześniejszych wersjach znalazłem coś takiego: https://vaadin.com/docs/v8/fr[...]ide/clientside-compiling.html - The Vaadin Client Compiler compiles Java to JavaScript. - Wibowit 2019-10-16 16:52
@Wibowit: ło panie, ale to co się działo za czasów javy 0.9 to już mniejsza :D future is here ---> https://vaadin.com/blog/webassembly-with-vaadin-flow - WeiXiao 2019-10-16 16:53
Jakiej Javy 0.9? Vaadin 8 wyszedł stosunkowo niedawno: On February 22, 2017, Vaadin Framework 8 was released. Dla WebAssembly Wiki podaje: First appeared March 2017, więc w tym samym czasie praktycznie. Jakoś ich to nie skłoniło do podmiany kompilacji Java -> JS na kompilację Java -> WASM. Zamiast tego porzucili w ogóle kompilację Javy do czegokolwiek innego. Ciekawe czemu? - Wibowit 2019-10-16 16:59
WebAssembly was first announced in 2015,[15] and the first demonstration was executing Unity's Angry Bots in Firefox,[16] Google Chrome,[17] and Microsoft Edge.[18] - WeiXiao 2019-10-16 17:00

Pozostało 580 znaków

2019-10-16 16:44
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.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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

Użytkownik: Mateusz Całka