Blazor WebAssembly Goes GA!

Blazor WebAssembly has officially made it to its first production release. In this post, I'm going to talk about some of the great features which shipped in that release; as well as look ahead to highlight some of the features I have my eye on for .NET 5 due in November.

We've made it! Blazor WebAssembly was officially released at Build 2020 and marks a significant milestone in Blazor’s history. It's easy to forget that a little more than two years ago Blazor didn't even exist, and the idea of being able to write rich, interactive client-side web UI with C# was just a dream—in fact I think it's fair to say many of us didn't even dream about it, it was just not something that was going to be a possibility. But look where we are now.

In this post I'm going to summarize the new features that made it into the Blazor WebAssembly (Wasm) GA release, as well as highlight some upcoming features we have to look forward to in .NET 5.

New Features

We had five previews and a release candidate before Blazor Wasm went GA at Build. And just like the majority of Blazor releases, they were packed with cool new features. I'm not going to list all of them here, but I do want to highlight the ones that really excited me and may be of interest to you if you missed them.

Reduced Download Size

There were big reductions in the size of the initial download for Blazor apps. The first of these came from a more aggressive setting for the IL linker. If you're not familiar with the linker, its job is to trim any unused code from your application in order to make it as small as possible. If you've worked with any JavaScript SPA frameworks, such as Angular, it's a similar concept to tree shaking.

Historically, the linker had only trimmed code from the core framework libraries. But it's now been reconfigured to also trim code from the Blazor framework assemblies as well. This resulted in about 100 KB being saved.

However, the biggest win came from enabling Brotli compression when publishing an app. Brotli is a very efficient compression format and implementing it led to the default Blazor template application going from 2MB to 1.8MB. If the Bootstrap CSS is removed, the size can go as low as 1.6MB.

Token-Based Authentication

Authentication is always a hot topic in web development, and Blazor is no exception. I wrote a series on it for my blog and those posts are always among my most popular every month. For Blazor Wasm, an out-of-the-box solution was a missing piece of the puzzle, but in Preview 2 we got that missing piece.

The implementation allows Blazor apps to use authentication based on the OAuth 2.0 protocol via OpenID Connect—a common and widely used option for SPA applications. Blazor apps can now be configured to verify users against many commonly used identity providers such as:

• Azure Active Directory
• ASP.NET Core Identity and Identity Server
• Google
• Auth0
• Any other existing OIDC provider

Authentication is now available in the Blazor project templates, and if you're using Visual Studio, it can be configured using a few clicks. If you're using the .NET CLI, then you just need to add a few switches to your dotnet new command. You can, of course, retrofit this into an existing Blazor app and you can find all the information you need on the Blazor Docs site.

Progressive Web Application Template

If you've not heard of PWAs before, they're web applications that use modern browser APIs and capabilities to behave like native ones. This includes thing such as:

• The ability to be installed and run from their own app window, not just the standard browser one
• Offline capabilities: PWAs can load and operate when there is no network connection
• Automatic updating
• Ability to receive push notifications from a backend server

Usually, enabling PWA functionality involves the creation of something called a service worker, which is written in JavaScript. There is also a supporting file called manifest.json, which contains meta data about the application which is used when it's installed, things such as its name and what icons to use. With Blazor, the creation of these files is now done for you. All you have to do is simply tick a checkbox when creating your app.

Debugging Support

Preview 3 brought us a long-awaited feature, debugging for Blazor Wasm apps via Visual Studio or Visual Studio Code. Previously we had access to a very rudimentary form of debugging using the browser developer tools. We could set breakpoints against C# code in the browser tools and hit those breakpoints, but it was a very fiddly process to get working and most of the time just fell over. Personally, I became very used to using simple Console.Writeline statements to help me debug my code as it was a far more reliable way of doing things.

We now have a much more familiar experience: We can hit F5 and run our applications in debug mode from Visual Studio, set breakpoints and inspect values. This is definitely a big step forward, but I think it's fair to say we're not quite there yet. I still find this new debugging experience to be a bit brittle. I've often run my apps and been presented with a blank browser window that never goes anywhere. Usually a second or third attempt will bring it to life, but there is still room for improvement here.

Auto-Rebuild in Visual Studio

While I know a lot of people are desperate for a feature known as hot reload, we did get a step closer to that with auto-rebuild in Visual Studio. With auto-rebuild you can make changes to your app and save them, then simply refresh the browser and the app will automatically be rebuilt. The downside, of course, is that you will lose any state that your application has.

I appreciate that hot reload is the goal but I for one was happy to see this feature come in, as it at least saved me having to manually rebuild my apps before refreshing the browser. It's worth noting however, that this is only available for hosted Blazor Wasm apps and not standalone ones.

Localization and Time Zone Support

The final new features are localization and time zone support. Localization was added in Preview 4 and allows developers to use the standard ASP.NET Core localization system to localize their components. There's support for different languages as well as culture-specific date and number formatting.

Time zone support was added in the last Preview, 5. It allows Blazor to infer the user's time zone so that it can be used in date and time calculations.

Looking Ahead to .NET 5

There have been some great features delivered for the launch of Blazor WebAssembly that will make building and using the applications so much better. But there's also so much yet to come.

We're only scratching the surface of what Blazor can do. So I thought it would be good to finish up with a few highlights I've spotted on the roadmap for .NET 5, due for release in November.

• Restrict Parent and Child Component Hierarchy—I'm very interested in this for my open-source projects. Essentially, this feature will allow us to restrict what child components can be placed inside a particular parent component.
• Required Parameters—With this we will be able to specify if certain parameters on our components are mandatory.
• Influencing HTML Head from a Blazor Component—This is such an important one for applications that need good SEO. There are ways of doing this now, but there are no established patterns.
• AoT Compilation—A highly requested feature, but also often misunderstood. AoT will be great for improving the performance of Blazor apps, but it comes at a cost, and that is size. To my understanding, the current thinking here is that developers will be able to choose to compile performance-sensitive parts of their application directly to Wasm while the rest will compile to DLLs. This should give the best tradeoff between performance and size.
• Real Multithreading—This one is very reliant on browser adoption as at the time of writing the only browser vendor supporting threading in Wasm is Chrome. But the ability to use threads has already been added to Mono, the runtime used by Blazor Wasm.
• Hot Reload for Blazor—Another very sought-after feature. The way this will be work is still being worked on, but it will be a very welcome feature if it lands in November.
• Lazy Loading of Application Areas—Similar to lazy loading in JavaScript apps, this would allow only the currently needed parts of your application to be loaded initially. Then other parts would be loaded as the user requests them. The idea is to lower the initial download needed to run the application.
• CSS Isolation in Blazor Components—A common feature found in other SPA frameworks such as Angular and React. This has been another popular feature requested by the community. If you've not used CSS isolation before, it allows you to write CSS for a component without needing to worry about those styles colliding with others in your app. This is achieved by applying unique CSS class names, automatically, at build time.

For the full list of features planned for .NET 5 you can check out the roadmap issue on GitHub.

That's where we're going to end things for this post. I hope you're just as excited as I am to see Blazor WebAssembly make it to general availability with so many great features available. I also hope you're equally as excited for Blazor’s future!