Is it true that the browser will need to download the WebAssembly library every time the page loads?

No, browsers can cache the files. Common CDNs for Blazor applications will do the trick.

Is this system faster to work than, for example, React / Vue.js, compiled in JavaScript?

Blazor uses WebAssembly, On paper WebAssembly should be faster than any JavaScript library. However, not all browsers have a mature WebAssembly parser yet. So you might find that browsers will not run WebAssembly in an optimal speed as of now.

You can create a small Blazor application and run it in Firefox, Chrome or Edge. In most cases, Firefox runs Blazor applications much faster than Chrome or Edge, which implies that browser makers still need to improve, and even Firefox can improve.

If your application needs to access the DOM frequently, then definitely WebAssembly / Blazor will be slower compared to any JavaScript libraries since WebAssembly can’t directly access the DOM without using Invokes (which is slow at the moment. Please refer my Blazor benchmark below).

On Firefox, 10,000 RegisteredFunction.InvokeUnmarshalle calls to empty methods takes 250 ms while Chrome and Edge need more than 2400 ms in my PC. In pure JavaScript it takes below 10 milliseconds for the same scenario.

Additionally, the current implementation of Blazor has its own MSIL engine on top of the browser's WebAssembly engine, which means there are two interpreters working to run a Blazor project, like two translators interpreting a conversation instead on one. Currently Microsoft is working on an AOT compiler, which is not yet released. Once it's released, Blazor will be much faster than the current implementation.

Mono and WebAssembly - Updates on Static Compilation

We can safely assume that the web assembly is the future of web development, but at the moment we can’t say anything about Blazor’s future. On paper, Blazor can be faster than any framework out there, however we need commitment from WebAssembly maintainers, browser developers, Microsoft and the communities to make the theories practical.

Update 10th July 2018

There are new proposals in the WebAssembly repositories.

1. Allowing WebAssembly to handle DOM directly. Interface types #8

2. Reference Types for WebAssembly with GC. Reference Types for WebAssembly

The above two proposals will pave the path to much faster interaction between the DOM and WebAssembly in the future. In other words, Blazor will be much faster in the future.

Update 17 October 2018

The Firefox team was able to reach a JavaScript-to-WebAssembly call as fast as JavaScript-to-JavaScript method calls. As of now Firefox is far ahead of any other browsers when it comes to WebAssembly support.

Calls between JavaScript and WebAssembly are finally fast

As I understand it, Blazor uses WebAssembly to compile C# on the client side.

Half true. You can write your code to WebAssembly (WASM) client side (yes, it is C# on the client side), but you can also execute the logic server side. Both have benefits. All your code is visible if you go the WASM route. But it can rerender faster than if the logic is all server based -- but if it's server based your code isn't viewable.

Does this approach run faster than, for example, React / Vue.js, compiled in JavaScript?

No. I've done a ton of Vue.js and Vue.js runs faster. But I can write code a lot faster using Blazor. And Blazor offers a virtual scrolling solution that can make it appear faster. In my case the available plotting components were too slow. I wrote a Blazor component using C# and JavaScript that worked very well. Most of the time I don't worry about the WASM code running too slow...but the plotting needed to be much faster...and Blazor let me have my cake...I just had to do some low level work in JavaScript. Blazor execution has gotten faster over the last six months and the team says there is more to come when .NET 6 comes out. But it's more than fast enough for 99% of what I've ever need to do.

Is it true that the browser will need to download the WebAssembly library every time the page loads?

Not if they are cached. And even the first time they load, it isn't slow if you have a decent connection. It is on the order of 10 MB.

The great unasked question -- is it worth using? I've been using it for about six months.

For me it has been great. C# is a very good language. Sometimes I miss adding a property dynamically and often you have to manually initiate a redraw, but with features like nullable object checks warning you that you didn't check if your code could cause a null reference check -- it is much better than JavaScript. I often felt it was painful to work with the JavaScript "toolchain". It is so nice to be able to opt out of the library thrash of JavaScript.

On April 2021 we did a trial of Blazor WASM against a legacy Angular.js web app, as well as against Flutter Web (HTML & CanvasKit renderers). We've recreated the main page of the legacy app (which is essentially a big data grid with filters, pagination, sorting etc.). Here're a few takeaways:

                                                                      Lighthouse perf. Scores
Grid Displ.  Data transf.  Data uncomp.  Reqs.  FCP   SI   LCP  TTI  TBT  CLS
Blazor*            2.2s         4.7MB         13.7MB        99     0.5s  1.6s 0.5s 2.1s 1.3s 0.01
Flutter HTML       1.7s         2.1MB          3.7MB        15     1.9s  2.5s 2.2s 2.3  0.2s 0
Flutter CanvasKit^ 2.8s         4.7MB         10.5MB        17     1.0s  2.2s -/-  2.2s 1s   0
AngularJS`         1.9s         2.0MB          5.7MB        294    2.1s  2.2s 2.6s 2.6s 0.1s 0

• Grid Displ. - time it took to completely display the gird (judging by the timeline and screenshots gathered by Lighthouse)
• Data transf. - data transfered when loading the app (Network tab in DevTools, caches cleared)
• Data uncomp. - uncompressed size of data transfered (Network tab)
• Reqs. - number of requests issued while loading the app (Network tab, caches cleared)
• Lighthouse Performance score breakdown
• Tested on Windows 10, Google Chrome Version 89.0.4389.128 (Official Build, 64-bit), Intel Core i5 4460, 16GB RAM, wired LAN connection
• Relase configs used to build apps, Blazor WASM/.NET 5, Flutter (Channel beta, 2.1.0-12.2.pre), AngularJS 1.7.7

*Lighthouse gives incorrect LCP value (it counts Blazor's blank 'Loading...' page as LCP)

^Flutter's CanvasKit renderer doesn't allow Lighthouse to get LCP measurement

`Legacy app is much bigger then PoCs created, there're many more screens and assets which affect the number of requests upon app launch

The ASP.NET Core roadmap for .NET 6 can be found on github here. You will find that Blazor has by far the most tasks.

Note that the list indicates those items the ASP.NET team will be focusing on meaning that they are putting alot of their emphasis on improving Blazor.

This issue represents the list of major investments our team will focus on during .NET 6 timeframe. The items on this list are only major areas of investments, and do not include all the features and bugfixes we will be tackling during this time.

Below are some of the tasks they have been working on:

Tasks completed:

1. AOT Compilation. Compile everything to WebAssembly

2. Improve SVG support in Blazor. Top-level issue for SVG support in Blazor

3. Support byte-array transfer in JS Interop.

Tasks in progress

1. Hot reload for Blazor. Build performance optimization

2. Pause and resume Blazor applications.

3. Target and deploy to desktop platforms.

4. Remove size limitations imposed by SignalR message size.

5. Drag & Drop. Provide events that users can subscribe to during drag and drop