Blazor can run your client-side C# code directly in the browser, using WebAssembly. Because it's real .NET running on WebAssembly, you can re-use code and libraries from server-side parts of your application. That is the official definition, direct from Microsoft.
It's worth taking a look at the client side technology that enables .NET to run in the browser and on mobile devices.
- WebAssembly (WASM) is a new client-side technology that enables near-native performance without plug-ins in all modern browsers, including mobile.
- WASM is Low level byte code, and you can compile to it.
- WASM is more of a target.
- Many languages, including C, C#, Go, and Rust, can compile code that targets the stack-based WASM virtual machine.
- WASM makes running .NET code literally anywhere, including inside the browser, possible.
- Blazor is a client-side library that uses .NET on WASM to support Single Page Applications written in C# using Razor templates.
- Blazor enables code reuse and the ability to port legacy code to modern web applications.
The browser itself hosts Blazor
The browser loads .NET DLLs that contain the compiled IL code.
Compiled IL code runs in the browser without a plugin. As the name suggests this is possible thanks to the WASM standard.
In most scenarios the application is autonomous. It handles user actions and other events in the browser itself and doesn’t callback the server.
One of the first modes or hosting models to surface from Microsoft was actually a first version of what we now refer to as ‘Blazor WebAssembly’ This would prove to be a very challenging problem to overcome with WASM itself still unstable and not fully supported across all browsers.
We will need to go nearly a decade to see how the ideas for this came about with contributions from a number of sources, including Chris Dunelm, to develop a stripped down version of .NET that would run on a super compact runtime, capable of targeting a wider set of devices, know as DotNetAnywhere.
If we then jump forward 5 years we arrive at Steve Sanderson picking up and running with DotNetAnywhere/Mono development with the goal of running it in WASM . Running .NET in the browser.
After a fantastic start and complete vertical slice being able to run and output strings and plaintext from C#, running in the browser, there was still a lot of work to do in order to interact and create a programming pipeline with DOM updates and support for emerging web standards.
And much of the progress gained from solving these design goals led to Blazor Server, which in many ways acts as a lighter alternative, server based version of Blazor.
In the meantime, WASM becomes a stable release and supported by all modern browsers, including mobile. Several languages have adopted WASM as a valid compilation target. You can build WASM programs using C, C++, Go, Rust, TypeScript, and dozens of other languages. It has been implemented in solutions for computer vision, audio mixing, video codec support, digital signal processing, medical imaging, physical simulations, encryption, compression, and more.
But what about C#?
Immediately after WebAssembly was introduced, work began to port a working version of the .NET Framework (including its Common Language Runtime) to run on WebAssembly.
The effort was successful.
How does it work
We write our code in C# and that just gets compiled to dynamic link libraries (dlls).
Then, in the browser, Blazor runs on top of the Mono .NET runtime and that is where it gets compiled to WebAssembly. So Mono is compiled to WebAssembly. That loads C# dlls and executes C# code in the browser
The Blazor app, its dependencies, and the .NET runtime are downloaded to the browser. The app is executed directly on the browser UI thread. UI updates and event handling occur within the same process. The app's assets are deployed as static files to a web server or service capable of serving static content to clients. Because the app is created for deployment without a backend ASP.NET Core app, it's called a standalone Blazor WebAssembly app.
blazor.webassembly.js script is provided by the framework and handles:
- Downloading the .NET runtime, the app, and the app's dependencies.
- Initialization of the runtime to run the app.
Caveats / Considerations
There are a few things to consider when choosing WebAssembly as a target for your Blazor application.
- The application is restricted to the capabilities of the browser.
- Capable client hardware and software (for example, WebAssembly support) is required.
- Download size is larger, and apps take longer to initially load.
- .NET runtime and tooling support is less mature. For example, limitations exist in .NET Standard support and debugging.
The Blazor WebAssembly hosting model offers several benefits:
- There's no .NET server-side dependency. The app is fully functioning after it's downloaded to the client.
- Client resources and capabilities are fully leveraged.
- Work is offloaded from the server to the client.
- An ASP.NET Core web server isn't required to host the app. Serverless deployment scenarios are possible (for example, serving the app from a CDN).
It's important to remember that either the Blazor WebAssembly or Blazor Server hosting models are based on ASP.NET Razor syntax that mixes HTML code, C# code and specific Blazor tags to create dynamic web-pages. Both hosting modes rely on the same razor syntax.
What happens internally to render the page and handles updates with a Blazor Server app is completely different. However, these differences also offer opportunities to solve problems in interesting ways.
It will be down to the domain and the specific application requirements to determine the best fit or even a combination of hosting models and approaches. with the advent of microservices, also comes patterns such as microfrontends. With so much capability at our fingertips, we are likely to see some amazing solutions emerge utilisng all that Blazor has to offer.
Stay tuned as we continue to explore Blazor in more detail and discover ways to mix both hosting models in future posts.