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

Odpowiedz Nowy wątek
Wesoły Ogrodnik
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

2020-02-12 19:17

Rejestracja: 14 lat temu

Ostatnio: 4 minuty temu

1

No to w takim razie trzeba tego Blazora testować w takich scenariuszach.

Właśnie się zorientowałem, że w https://github.com/krausest/js-framework-benchmark są wyniki WASMowej aplikacji. Wystarczy wejść na https://rawgit.com/krausest/j[...]bdriver-ts-results/table.html w frameworks wybrać "vanillajs-keyed" i "wasm-bindgen-v0.2.47-keyed" i mamy porównanie Vanilla.JS kontra WASM-bindgen czyli konkretnie to: https://github.com/krausest/j[...]keyed/wasm-bindgen/src/lib.rs

wasm-bindgen jest średnio 5% wolniejszy od vanilla.js


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

Pozostało 580 znaków

2020-02-12 21:17

Rejestracja: 1 rok temu

Ostatnio: 1 minuta temu

1
Wibowit napisał(a):

Framework webowy to powinien raczej celować w wydajność stron z masą tabelek, formularzy, ramek, zakładek, dialogów, odświeżania danych na żywo, logiki biznesowej itp itd a nie wydajność grafiki 3D czy jakichś typów obliczeń praktycznie nigdy nie będących wąskim gardłem w webówce.

Poza tym nie zapominajmy o asm.js:
https://hacks.mozilla.org/201[...]r-with-float32-optimizations/
https://blogs.unity3d.com/2018/08/15/webassembly-is-here/
https://medium.com/@torch2424[...]bassembly-vs-es6-d85a23f8e193
https://blog.acolyer.org/2017[...]up-to-speed-with-webassembly/

WebAssembly is on average 33.7% faster than asm.js, with validation taking only 3% of the time it does for asm.j.s
WebAssembly binaries are also compact, being on average 62.5% the size of asm.js, and 85.3% of native x86-64 code.

Czy "33.7% faster" to nieporównywalnie szybszy? Może po prostu źle coś zakodziłeś w JSie?

  1. asm.js to co innego niż vanilajs. Zwykle nie pisze się go z ręki, tylko kompiluje (Emscripten ). W mojej opinii to taki krok pośredni w ewolucji do WASM, bo w większości przypadków ta sama biblioteka/framework generuje asm i wasm, wykrywane jest wsparcie i asm służy jako opcja dla gorszych przeglądarek. To z resztą nawet jest wprost napisane: "asm.js is mostly superseded by WebAssembly."
  2. threejs, babylonjs i inne biblioteki 3D nie wykorzystują ani asm, ani wasm w wersji podstawowej. Można znaleźć implementacje experymentalne.
  3. Te 33.7% w grafice 3d to przepaść. Od tego zależy, czy aplikacja będzie miała 19 fpsów, czy 29 fpsów na określonym urządzeniu. W dużych produkcjach zyskanie 1 milisekundy uważa się za sukces.
  4. Ta wartość 33.7% jest pewną wartością uśrednioną i składają się na nią następujące rzeczy:
    a. To porównanie z asm.js, nie ze zwykłym jsem
    b. Jak przejrzy się wykres wydajności, to widać znaczne różnice z uwagi na konieczność interpretacji js. W zwykłym jsie pierwsze wykonanie funkcji zwykle oznacza chwilowy spadek wydajności, widoczny w FPSach - będzie to widoczne jako chwilowe przycięcie aplikacji, chociaż teoretycznie średnia nie odzwierciedli tego.
    c. W porównaniu obliczeń JS vs WASM zwykle przegrywa 4 krotnie (z moich testów tak wynika), ale tego nie sposób porównać, bo różne silniki mają różną wydajność dla różnych operacji.
    d. Wiele powszechnie używanych funkcji jest bardzo skutecznie zaimplementowana w powszechnie używanych przeglądarkach i praktycznie nie ma różnicy JS vs WASM, ale akurat nie dotyczy to takich zastosowań jak grafika 3d.

Dobrze zakodziłem w JSie. Porównywałem identyczne algorytmy.

edytowany 2x, ostatnio: renderme, 2020-02-12 21:19
Dodam, że więcej zastosowań widzę dla WASM niż grafika 3d. Kiedyś robiłem też apkę opartą o mapy i tam też są dość ciężkie obliczenia, które warto wypchnąć na wasm. - renderme 2020-02-13 10:31

Pozostało 580 znaków

2020-02-17 01:47

Rejestracja: 3 lata temu

Ostatnio: 10 godzin temu

0

Steve Sanderson on Blazor at NDC London: gRPC, Testing, and PWA capability

00:00 - 11:00: Talks about basic Blazor stuff previously known.

11:00 - 17:35: Shows binding to make a kind of dividing bar like on Humble Bundle.

17:35 - 31:15: Makes a product scanner "Blazor Mart" with Blazor + gRPC.

31:15 - 43:00: Test driven development to implement 'remove item' functionality.

43:00 - 48:00: Makes it a PWA by adding a service worker for temporary offline use.

48:00 - 49:50: Makes the web app installable in your OS (again, PWA).

49:50 - end: Talks about Server-side vs WebAssembly, 'Hybrid Blazor' (Electron). Shows of the beginning of 'Blazor + Native UI' for native mobile and desktop applications (no release date announced).

edytowany 1x, ostatnio: WeiXiao, 2020-02-17 01:47
Hippsters gonna hip - somekind 2020-02-17 01:53
że hipopotamy? no ok ;) - WeiXiao 2020-02-17 01:54

Pozostało 580 znaków

dziś, 09:26

Rejestracja: 1 rok temu

Ostatnio: 54 minuty temu

0

Kolejna prezentacja z NDC:

In this talk, Blazor's two architects will take you deeper into the framework, showing a range of more advanced features and their internal workings.

We'll dig into server-side Blazor and how we built the SignalR-based mechanism for efficiently streaming UI updates. Plus we’ll give you a guided walkthrough of how to build a high-quality redistributable Razor Class Library complete with friendly APIs, a static asset build system, and continuous deployment.

Pozostało 580 znaków

dziś, 10:54

Rejestracja: 1 rok temu

Ostatnio: 9 minut temu

Lokalizacja: Silesia

0
wloochacz napisał(a):

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

Trochę odgrzewam, ale przypadkowo trafiłem na taki wpis WASM is slow. Dla wyjaśnienia TeaVM jest kompilatorem i maszyną wirtualną dla pomysłu Java -> Wasm.
Wpis ten skłonił mnie do refleksji jak często ludzie zakłamują benchmarki (świadomie lub nieświadomie). Piszą jakiś ładny kod proceduralno-matematyczny działający tylko na stosie. Nie używają sterty ani obiektów. I wychodzą im bardzo ciekawe wyniki.
Błąd polega na tym, że w normalnym życie tworzymy obiekty i mocno używamy sterty. W OOP - dużo, w OOP + FP - bardzo dużo (obiekty są mniejsze, niemutowalne i mają krótszy czas życia).

Teraz zastanawiam się czy by nie napisać jakiejś małej normalnej aplikacji (nie matematycznej) w Javie lub Scali (C# nie znam). Raz skompilować do JSa a raz do WASM i porównać wyniki. Oczywiście wynik i tak będzie obarczony niedoskonałościami transpilerów do JS i kompilatorów do WASM :/


Pozostało 580 znaków

Odpowiedz

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