Blazor is a .NET web framework for building interactive UIs with C#, HTML, and Razor components.
Its main appeal is that it allows you to use C# and share .NET code across different parts of your application. JavaScript doesn’t disappear (the browser still has its own APIs), but it’s no longer mandatory for a large part of your UI logic.
Blazor does not transpile your C# code to JavaScript.
Blazor runs real .NET code, either on the server or directly in the browser using WebAssembly.
Why use Blazor
The main advantage is productivity. If you already know the .NET ecosystem, you don’t have to switch mental contexts to write the frontend.
There are also strong technical reasons:
- Shared Code: You can use the same classes (DTOs, validations, models) on the client and the server. Say goodbye to duplicating your object definitions in TypeScript.
- Ecosystem: You have access to standard .NET NuGet libraries.
- Tooling and Typing: You benefit from C#‘s static typing, dependency injection, and the debugging tools of the .NET ecosystem.
How does it work internally?
Blazor is based on a component architecture. A Blazor application is nothing more than a tree of components that are rendered to form the user interface.
These components are written in files with a .razor extension, which mix standard HTML with C# syntax.
<h3>Counter: @currentCount</h3>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}Internally, Blazor maintains an in-memory representation of the DOM (a “Render Tree”). When state changes (for example, on a click), Blazor calculates the diff and updates only the necessary parts of the real DOM.
Rendering Modes (.NET 8+)
The evolution of the technology introduces an interesting nuance that often creates confusion.
Until .NET 7, you had to choose your “side” when creating the project: Blazor Server or Blazor WebAssembly. They were separate project types.
Since .NET 8, Microsoft unified everything under the concept of the Blazor Web App. Now, “Server” and “WebAssembly” are no longer just separate project types, but rendering modes you can choose on a per-component basis.
Let’s look at the options available today.
In this mode, the application runs entirely on the server.
The browser acts as a “dumb terminal”. A SignalR connection (WebSockets) is established between the client and the server. When you click a button, the event travels to the server, the C# is processed, and the server sends back the exact changes needed to update the HTML.
- Advantages: Initial load is very fast (no need to download .NET libraries). You have direct access to the database and server services.
- Disadvantages: You need a permanent connection. If the internet goes down, the app stops responding. Latency can be an issue if the server is far away. It consumes a lot of memory on the server per connected user.
Here, the application (your code’s DLLs and a stripped-down version of the .NET runtime) is downloaded to the browser and runs there using WebAssembly.
- Advantages: Execution and interactive rendering happen on the client, so it doesn’t need a permanent circuit to the server.
- Disadvantages: Initial load is slower (you have to download the .NET runtime, though it is cached).
Running the UI with WebAssembly does not automatically make the application offline-capable. For that, you need a PWA, store the required resources, and also design offline access to data.
This is the default option in modern templates. The page is rendered on the server and sent as pure HTML to the browser.
There are no WebSockets and no WebAssembly. It works like older websites (or MVC/Razor Pages), but uses Blazor component syntax. It’s ideal for pages that don’t require complex interaction, like blogs or landing pages, and it’s perfect for SEO.
The Auto mode is one of the most interesting new features in .NET 8+. It combines the best of both worlds.
- When the user enters for the first time, the component uses Interactive Server.
- In the background, the browser downloads the WebAssembly files.
- Once the package is available, subsequent visits can use Interactive WebAssembly.
The Auto mode avoids waiting for WebAssembly to finish downloading on the first visit. The chosen mode is maintained while the component remains on the page; it does not hot-migrate its state from the server to the browser.
Comparison of Interactive Modes
For a quick overview, we can compare the modes like this:
| Feature | Server | WebAssembly | Auto |
|---|---|---|---|
| Execution location | Server | Browser | Both |
| Initial load | Fast | Higher (downloads runtime) | Fast on first visit |
| Permanent connection | Yes (SignalR) | No | Only while using Server |
| Resource access | Full server | Browser sandbox | Both |
Which one should I choose?
As a starting point, you can follow this guideline:
- Start by creating a Blazor Web App.
- Use Static Server Rendering (SSR) for public pages, simple forms, and static content (Login, Home, About).
- Use Interactive Auto when you want a quick initial response and the component can also run in the client project.
The final choice depends on latency, server load, download size, and the component’s need for server resources.
In the next article, we’ll roll up our sleeves to prepare our environment and create our first project to dissect its structure.
