Chciałbym zacząć używać Blazora, mimo że wciąż jest na poziomie alfa.

Jak rozumiem, Blazor używa WebAssembly do kompilacji C # po stronie klienta.

Mam te pytania:

Czy to podejście działa szybciej niż, na przykład, React / Vue, skompilowane w JavaScript?

Czy to prawda, że ​​przeglądarka będzie musiała pobierać bibliotekę WebAssembly za każdym razem, gdy strona się ładuje?

W Internecie nie ma porównań wydajności popularnych frameworków JS. Chciałbym więc poznać teoretyczną wydajność nowego frameworka firmy Microsoft. Z góry dziękuję.

Czy to prawda, że ​​przeglądarka będzie musiała pobierać bibliotekę Webassembly za każdym razem, gdy strona się ładuje?

Nie, przeglądarki mogą buforować pliki. Wspólny CDN dla aplikacji Blazor załatwi sprawę.

Czy ten system działa szybciej niż na przykład React / Vue skompilowany w JavaScript?

Blazor używa zestawu internetowego, na papierze zestaw sieciowy powinien być szybszy niż jakakolwiek biblioteka js, jednak nie wszystkie przeglądarki mają jeszcze dojrzały parser zestawu internetowego. Może się więc okazać, że obecnie przeglądarki nie będą uruchamiać asemblera internetowego z optymalną szybkością.

Możesz stworzyć małą aplikację blazor i uruchomić ją w przeglądarce Firefox, Chrome lub Edge. W większości przypadków Firefox uruchamia aplikacje blazor znacznie szybciej niż Chrome lub Edge, co oznacza, że ​​twórcy przeglądarek nadal muszą ulepszać, nawet Firefox może to robić.

Jeśli Twoja aplikacja musi często uzyskiwać dostęp do DOM, to zdecydowanie web assembler / Blazor będzie wolniejszy w porównaniu do jakichkolwiek bibliotek JS, ponieważ web assembler nie może uzyskać bezpośredniego dostępu do DOM bez użycia Invokes (co jest obecnie wolne, zapoznaj się z moim testem porównawczym Blazer poniżej) .

W przeglądarce Firefox 10 000 RegisteredFunction.InvokeUnmarshallewywołania metod pustych trwają 250 ms, podczas gdy chrome i edge potrzebują więcej niż 2400 ms na moim komputerze ”. W czystym JS zajmuje to mniej niż 10 milisond dla tego samego scenariusza.

Ponadto bieżąca implementacja Blazor ma własny silnik MSIL na szczycie silnika składania sieci Web przeglądarek, co oznacza, że ​​istnieją dwa tłumacze pracujące nad uruchomieniem projektu Blazor, podobnie jak dwóch tłumaczy interpretujących konwersację zamiast na jednym. Obecnie Microsoft pracuje nad kompilatorem AOT, który nie został jeszcze wydany. Po wydaniu Blazor będzie znacznie szybszy niż obecna implementacja.

http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/

Możemy spokojnie założyć, że montaż sieciowy jest przyszłością tworzenia stron internetowych, ale w tej chwili nie możemy powiedzieć nic o przyszłości Blazor. Na papierze Blazor może być szybszy niż jakikolwiek framework, jednak potrzebujemy zaangażowania ze strony opiekunów zestawów internetowych, programistów przeglądarek, firmy Microsoft i społeczności, aby teorie były praktyczne.

Aktualizacja z 10 lipca 2018 r

W repozytoriach WebAssembly są nowe propozycje.

1. Umożliwienie WebAssembly bezpośrednio obsługi DOM. https://github.com/WebAssembly/proposity/issues/8

2. Typy odwołań dla WebAssembly z GC. https://github.com/WebAssembly/reference-types/blob/master/proposity/reference-types/Overview.md

Powyższe dwie propozycje utorują drogę do znacznie szybszej interakcji między DOM a webassembly w przyszłości. IOW Blazor będzie w przyszłości znacznie szybszy.

Aktualizacja z 17 października 2018 r

Zespół Firefoksa był w stanie dotrzeć do wywołań JS -> WASM tak szybko, jak wywołania metod JS -> JS. Na razie FireFox znacznie wyprzedza wszelkie inne przeglądarki, jeśli chodzi o obsługę WebAssembly

https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/

Jak rozumiem, Blazor używa WebAssembly do kompilacji C # po stronie klienta.

W połowie prawda. Możesz napisać swój kod po stronie klienta WebAssembly (WASM) (tak, jest to C # po stronie klienta), ale możesz również wykonać po stronie serwera logiki. Obie mają zalety. Cały twój kod jest widoczny, jeśli wybierzesz trasę WASM. Ale może renderować ponownie szybciej niż wtedy, gdy logika jest oparta na serwerze - ale jeśli jest oparty na serwerze, kod nie jest widoczny.

Czy to podejście działa szybciej niż, na przykład, React / Vue, skompilowane w JavaScript?

Nie. Zrobiłem mnóstwo Vue i Vue działa szybciej. ALE mogę pisać kod dużo szybciej, używając Blazor. A Blazor oferuje rozwiązanie do wirtualnego przewijania, które może przyspieszyć wyświetlanie. W moim przypadku dostępne komponenty kreślące były zbyt wolne. Napisałem komponent Blazor przy użyciu C # i JavaScript, który działał bardzo dobrze. Przez większość czasu nie martwię się, że kod WASM działa zbyt wolno ... ale kreślenie musiało być znacznie szybsze ..... i Blazor pozwolił mi zjeść ciasto ... po prostu musiałem zrobić trochę nisko poziom pracy w JavaScript. Wykonanie Blazora przyspieszyło w ciągu ostatnich 6 miesięcy, a zespół twierdzi, że gdy pojawi się .Net 6, będzie jeszcze więcej. Ale jest wystarczająco szybki, aby wykonać 99% tego, co kiedykolwiek musiałem zrobić.

Czy to prawda, że ​​przeglądarka będzie musiała pobierać bibliotekę WebAssembly za każdym razem, gdy strona się ładuje?

Nie, jeśli są buforowane. Nawet gdy ładują się po raz pierwszy, nie jest powolny, jeśli masz przyzwoite połączenie. Jest rzędu 10 meg.

Świetne nie zadane pytanie - czy warto skorzystać. Używam go od około 6 miesięcy. Dla mnie było świetnie. C # to bardzo dobry język. Czasami brakuje mi dynamicznego dodawania właściwości i często trzeba ręcznie zainicjować ponowne rysowanie, ale z funkcjami takimi jak kontrole obiektów dopuszczających wartość null ostrzegającą Cię, że nie sprawdziłeś, czy Twój kod może spowodować sprawdzenie odwołania zerowego - jest znacznie lepszy niż JS. Często czułem, że praca z „toolchainem” JavaScript jest bolesna. Miło jest móc zrezygnować z bibliotekowego thrashu JS.