What’s Coming for Blazor in .NET 7?

.NET 7 is slated for release later this year, but what will it bring for us Blazor developers?

The first few ASP.NET 7 preview releases have been released and you may have noticed they haven’t included many (if any) Blazor changes. Reading between the lines, this is likely a result of the team’s focus on .NET MAUI.

Dan Roth indicated (during a recent ASP.NET Community Standup) that .NET MAUI will be the first big Blazor-related release in 2022. 

.NET MAUI is poised to bring Blazor to native application development, making it possible to build applications for Windows, Mac, iOS and Android using your Blazor knowledge and skills.

Once .NET MAUI is officially released, we can expect to see some more significant Blazor improvements in the subsequent .NET preview releases. But what exactly can we expect?

Here’s a list, based on public comments and published GitHub issues, of possible new features and improvements which could land with .NET 7.

Hot Reload Improvements

.NET 6 introduced Hot Reload—the ability for your browser to automatically reflect the changes you make during development (without performing a full rebuild of the app).

While .NET 6 made some large strides with Hot Reload, the experience can still be a little hit and miss. There are plans with .NET 7 to plug some gaps in the existing Hot Reload support, including:

• Handling more edits (those which require a full restart of the server with .NET 6)
• Making it possible to use Hot Reload when debugging Blazor WASM applications
• Bringing Blazor WASM’s Hot Reload support up to par with support for other parts of .NET (such as ASP.NET Razor Pages, MVC)

AOT (Ahead Of Time Compilation) Improvements

.NET 6 introduced the ability to compile Blazor applications to WASM, bringing faster performance at the cost of increased app bundle size (AOT-compiled apps can be as much as 2x larger).

Without AOT, your Blazor WASM apps run using a .NET IL (Intermediate Language) Interpreter. Whereas the Interpreter is implemented in WebAssembly, your app isn’t.

Conversely, with AOT, your app is compiled directly to WebAssembly.

Microsoft is considering introducing an AOT mixed mode for .NET 7, which would enable you to use AOT selectively, for specific parts of your app. With this, you could use AOT for the “hot paths” in your app (where performance matters) without massively increasing the size of your overall app.

As well as mixed mode, the team is exploring ways to improve AOT performance:

• Tuning the AOT process (specifically to address areas where they currently have to bridge back to the interpreter, resulting in reduced performance)
• Exploring further ways to trim unnecessary code in order to bring the overall app size down

Multithreading

Blazor WASM currently runs on a single thread in the browser (specifically, it runs everything on the “UI Thread”).

Browsers have now introduced support for multithreading. This support existed previously but was disabled for a number of years due to security issues. Now that multithreading support is back, Microsoft is hoping to make use of it for Blazor in .NET 7.

The primary use cases are likely to be long-running tasks, and/or tasks that are compute-intensive. By moving this work onto separate threads, you would be able to keep your Blazor UI fast and responsive (while the work continues in the background).

.NET Web Assembly Without Blazor UI

If you want to build a web application with a UI that runs on WebAssembly, then Blazor WASM is a good fit.

But what if you want to use a .NET library in the browser without implementing a Blazor UI, say from a JavaScript application?

The proposed changes would enable you to take an existing .NET library and reuse it in the browser even if you weren’t using Blazor, thus opening the door for you to reuse all sorts of handy .NET libraries.

Improvements to Blazor Server Connection Management

With .NET 6 (and earlier), when you redeploy or restart your Blazor Server application, your users are likely to see a message requiring them to restart the application.

There are plans for .NET 7 to provide more control over the underlying SignalR circuit lifetimes as well as to support pause and resume for Blazor Server apps.

This would include a mechanism to hibernate component state and then, in the event that the browser lost connection to the server, restore that state when the app comes back up.

If MS pulls these changes off, it could address one of the primary concerns developers have about Blazor Server: how to handle lost connections to the server.

Prerendering With Auth

Prerendering makes it possible for your site’s visitors to interact with your Blazor site before the initial download has finished.

It works by performing an initial render on the server. HTML is then served to the browser, meaning your users have something to work with while the browser downloads the Blazor WASM .NET runtime (and your app) in the background.

One significant gap in Blazor prerendering has been around applications that require authentication.

To date, prerendering for routes that require authentication hasn’t really been possible, meaning you aren’t able to prerender any pages that show user-specific data.

It’s not yet clear exactly how this will work, but any solution will likely enable the server to access the user’s details during the prerendering phase.

@bind:after and @bind:get/set

Sometimes you may want to run some additional logic after a part of your UI has changed.

Steve Sanderson includes a handy example of this in the GitHub issue for this change:

<input @bind="searchText" @bind:after="PerformSearch" />

@code {
    string searchText;

    async Task PerformSearch()
    {
        // ... do something asynchronously with 'searchText' ...
    }
}

The proposed @bind:after directive seen here would make it much easier to run code in response to the searchText value being changed (in this case, by the user entering a new value in the input).

This is particularly useful because Blazor’s usual binding process, checks and failsafes, will have occurred, guaranteeing you access to up-to-date information from that searchText field when running logic in PerformSearch.

Blazor would also be able to invoke your code (in this case, your logic in PerformSearch) before any attempts to re-render your component, meaning you could safely make changes in PerformSearch that trigger further re-rendering without running into issues around performing too many chained re-renders.

To understand why this is a big deal, it’s useful to consider how you’d handle this today.

With .NET 6, there’s no obvious built-in way to react to binding changes. If anything, it would be easier to put a button next to the search so you had something concrete you could wire an event handler up to (to perform the actual search).

As well as @bind:after, and for more granular control over the binding process, there is also a proposal to introduce @bind:get and @bind:set directive attributes.

These would make it possible to implement your own Value and ValueChanged properties like so:

<input @bind:get="@SearchText" @bind:set="@SearchTextChanged" />

@code {
    [Parameter] public TValue SearchText { get; set; }
    [Parameter] public EventCallback<TValue> SearchTextChanged { get; set; }
}

This would expose the EventCallback to be invoked when the value in the search input changes.

Empty Templates

In addition to the standard Blazor project template which we all know and, um, love? Microsoft will also ship a simpler template, with less pre-existing code and UI.

There are also minor changes proposed to the existing templates, including simplifying the structure and redesigning the theme.

Micro Frontends?

Finally there are a number of proposed changes that would bring more flexibility to how you can incorporate Blazor into your web applications.

Specifically there are plans to:

• Mix Blazor Server and WASM (so you can use both within the same application)
• Run multiple Blazor apps on the same page (currently you can have only one)
• Render Blazor components from your JavaScript applications (and include them in your Angular and React applications)

You may have heard the term “micro-frontend architecture.” It’s an approach whereby traditionally larger (monolithic) frontend applications are split into smaller apps. Not dissimilar to microservices for backend development, this opens the door to using the “best tool for the job” when choosing which frameworks and tools to use to build parts of your UI.

These proposed changes for Blazor are a step in that direction, making it easier to adopt Blazor for some, but not necessarily all, of your web UI.

In addition, custom elements support will make it possible to register your Blazor components such that you can use them from your Angular and React applications.

Other General Improvements

Finally there are numerous, smaller, changes included in the current roadmap for .NET 7.

A few which catch the eye:

• A LocationChanging event for NavigationManager (implement logic that occurs before navigation takes place)
• DateOnly and TimeOnly support for Blazor routing
• Better MSAL support for additional scenarios (options to pass additional arguments to the underlying MSAL library, used when performing authentication in the browser)

In Summary

It’s worth noting that plans change and items mentioned here might not make the cut for .NET 7 (and items not currently included in the roadmap could yet be added), but these seem like solid bets for when .NET 7 is released in November 2022.

Reviewing the list, it’s interesting to consider the maturity of Blazor at this point.

After making big strides in recent years (from prototype to officially supported product), the proposed changes for Blazor in .NET 7 are generally incremental improvements, updates to tooling or expansion of the scenarios where Blazor can be used.

It seems the biggest “Blazor” changes are landing earlier in 2022 when .NET MAUI launches, bringing Blazor to the world of native app development.