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.
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.
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.
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:
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.
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:
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.
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.
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.
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.
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.
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!
Chris is a Microsoft MVP, software engineer and blogger with over 15 years experience working with ASP.NET. He is passionate about sharing his knowledge with the community and is an avid blogger and speaker. A strong believer in open source, he maintains several projects under the GitHub organisation, Blazored. He also contributes to other projects as much as possible. Chris is a proud member of the .NET Foundation. You can find Chris online at his blog chrissainty.com and on Twitter as @chris_sainty.