What is Blazor?
It’s a framework for browser-based (client-side) applications written in .NET, running under WebAssembly. It gives you all the benefits of a rich, modern single-page application (SPA) platform while letting you use .NET end-to-end, including sharing code across server and client.
Running .NET in the browser
The first step to building a .NET-based SPA framework is to have a way of running .NET code inside web browsers. We can, at last, do this based on open standards, supporting any web browser (without any plugins), thanks to WebAssembly.
So how does that let us run .NET? Well, the Mono team is adding support for WebAssembly. In case you missed the news, Mono has been part of Microsoft since 2016. Mono is the official .NET runtime for client platforms (e.g., native mobile apps and games). WebAssembly is yet another client platform, so it makes sense that Mono should run on it.
Mono aims to run under WebAssembly in two modes: interpreted and AOT.
In interpreted mode, the Mono runtime itself is compiled to WebAssembly, but your .NET assembly files are not. The browser can then load and execute the Mono runtime, which in turn can load and execute standard .NET assemblies (regular .NET .dll files) built by the normal .NET compilation toolchain.
This is similar to how, for the desktop CLR, the core internals of the CLR are distributed precompiled to native code, which then loads and executes .NET assembly files. One key difference is that the desktop CLR uses just-in-time (JIT) compilation extensively to make execution faster, whereas Mono on WebAssembly is closer to a pure interpretation model.
Ahead-of-time (AOT) compiled mode
In AOT mode, your application’s .NET assemblies are transformed to pure WebAssembly binaries at build time. At runtime, there’s no interpretation: your code just executes directly as regular WebAssembly code. It’s still necessary to load part of the Mono runtime (e.g., parts for low-level .NET services like garbage collection), but not all of it (e.g., parts for parsing .NET assemblies).
This is similar to how the ngen tool has historically allowed AOT compilation of .NET binaries to native machine code, or more recently, CoreRT provides a complete native AOT .NET runtime.
Interpreted versus AOT
Which mode is best? We don’t know yet.
What we do know is that interpreted mode provides a much faster development cycle than AOT. When you change your code, you can rebuild it using the normal .NET compiler and have the updated application running in your browser in seconds. An AOT rebuild, on the other hand, might take minutes.
So one obvious thought is that interpreted mode might be for development, and AOT mode might be for production.
But that might not turn out to be the case, because interpreted mode is surprisingly much faster than you’d think, and we hear from Xamarin folks who use .NET for native mobile apps that regular (non-AOT) .NET assemblies are very small and compression-friendly compared with AOT-compiled assemblies. We’re keeping our options open until we can measure the differences objectively.
Blazor, a SPA framework
Being able to run .NET in the browser is a good start, but it’s not enough. To be a productive app builder, you’ll need a coherent set of standard solutions to standard problems such as UI composition/reuse, state management, routing, unit testing, build optimisation, and much more. These should be designed around the strengths of .NET and the C# language, making the most of the existing .NET ecosystem, and packaged with the first-rate tooling support that .NET developers expect.
Blazor provides that. It’s inspired by today’s top SPA frameworks such as React, Vue, and Angular, plus some Microsoft UI stacks such as Razor Pages. The goal is to provide what web developers have found most successful in a way that fits neatly with .NET.