Chapter 5 Blazor

Figure 5-6.  Razor component lifecycle (Source: Microsoft)

Running a Blazor App

So, now we know how Blazor works. But how do we go from entering a URL in our browser to a running Blazor application? Is it a plugin like Silverlight was? Do we need browsers that support Blazor? The answer is simple. Blazor is not plugin based; it runs on WebAssembly. All we need is a browser that supports Wasm, and all modern browsers do. To understand how Blazor is loaded into a browser, we need to step back and look at a basic web server. A web server in its purest form is a server that hosts a bunch of files. Those files get downloaded to the browser of someone who enters the URL that routes to your webserver. Webservers have had a form of conventions, for

140

Chapter 5 Blazor

example, if no specific html file is specified in the URL, the server will, by default, look for index.html or default.html. Other web servers, like IIS, for example, also take this convention into account; index.aspx is still the startpage of an ASP.NET application. A Blazor WASM application is served as a static website; there’s no need for an IIS server to make the calculations or run the .NET code. All we need is a website that can serve static content, in this case HTML, CSS, JS, and DLL files.

Figure 5-7 shows the generated files when publishing a stand-alone Blazor WASM client application without PWA support from Visual Studio. The deploy step took our wwwroot content and copied it to the output folder; it compiled our .NET code and added that to the output as well.

Figure 5-7.  Output after publishing a Blazor WASM application

There is our index.html file! There’s HTML and CSS files right there; no need to compile or compute anything; a static file server can deliver these files to a modern browser; the browser will spin up the WASM runtime and load in the Blazor app. We don’t even need to install .NET 6 into our browser; notice that _framework folder in Figure 5-7? That contains the .NET 6 assemblies; it just ships with our application.

Figure 5-8 shows part of the contents of that folder.

141

Chapter 5 Blazor

Figure 5-8.  _ framework folder

There are some interesting files in this folder. I have removed a lot of the files from Figure 5-8 for brevity, but the interesting ones are still there. Before we go into the actual files, notice that there are three versions of the files? That is because the output generates every file in a normal way and twice using a different type of compression. The

.gz files are gzipped, while the .br files are compressed with Brotli. It is up to the server that serves our application to detect what the optimal type is for the client requesting our files.

142

Chapter 5 Blazor

Let’s start with the actual .NET 6 runtime. As you can see, the assemblies are there, in part. All the System.* files are part of the .NET 6 assemblies, while all of the Microsoft.* files are specific for Blazor. When publishing a Blazor application, the framework will run a linker process. This process will remove unreachable or unused code from the generated intermediate language files, and it will remove unused binaries from the output (tree shaking). These operations are not perfect. It is very important to perform a complete end-to-end test of your application after publishing. There is a possibility that the linker was too aggressive and that your application suddenly behaves in unexpected ways. To fix this, the linker can be configured to ignore certain modules by adding nodes to the project file. The complete documentation on how to do this can be found at https://docs.microsoft.com/en-us/dotnet/core/deploying/trim-self-contained.

The blazor.boot.json file contains information about the project. It contains a list of assemblies, with hashes to prevent tampering, that need to be loaded in order for the application to start.

blazor.webassembly.js is the glue between the web world, where the HTML lives, and the native world, where .NET lives. As mentioned before, we currently cannot directly access the DOM from within the .NET Blazor code. To work around this, Microsoft created this JavaScript file. Since we cannot interact with the elements in the visual tree from within Blazor, but we can call JavaScript functions through JS Interop, this file can serve as a bridge from Blazor to the visual tree.

BlazorWasmDemo.dll contains the application code we have written. dotnet.wasm is the native Webassembly code that contains the instructions to load

up the .NET runtime environment in the Webassembly sandbox.

Loading a Blazor WASM application means downloading all these files and loading them into the WASM sandbox. At first sight, that might look like a lot but the Blazor team has been hard at work to shrink .NET down as much as possible; combined with linking and tree shaking, they managed to get a Blazor WASM application to a reasonable size when compared with other JavaScript-based SPA frameworks. Figure 5-9 shows the browser’s network tab when opening a published Blazor WASM application, hosted on a static Azure website. This is an actual in-house application we are actively using and developing, so no demo application. Do keep in mind that the size on the screenshots is just for demo purposes, the actual size of your application will be different.

Figure 5-9.  Launching a published Blazor WASM app

143