The Practical Client

What's New in and Getting Started with Blazor 0.8.0.0

There are good reasons to keep working with Blazor 0.8.0.0 ... but you're going to need to make some changes.

• By Peter Vogel
• 02/20/2019

On Feb. 5 Microsoft announced the latest release of Blazor, the experimental (I can't say that enough) technology for building .NET applications that run in the browser. The server-side component of Blazor is already baked into .NET Core 3.0 (still in preview as I write this), but the client-side component doesn't yet have a release date, other than "sometime after .NET Core 3.0." Having said that, the higher version numbers for Blazor suggest that it will come out of experimental mode sometime in the second quarter of this year.

This revision focused on Blazor internals rather than new features: Server-side Blazor, the part baked into .NET 3.0, is now part of "Razor Components"; client-side Blazor is still just called "Blazor." There are, however, four changes that stood out for me.

Two are easy to describe:

• @implements is now supported in all .cshtml files (it's not just Blazor-specific) so that you can add interfaces (like IDisposable) anywhere you use .cshtml.
• Speed: Blazor is supposed to be about 25 percent faster on Chrome. I've never been unhappy with Blazor's performance (which is why I didn't test this) but faster is always better.

The Good News/Bad News Story
The third change is a good news/bad news story. As of Visual Studio 2019, Blazor is included with Visual Studio instead of being an "add-on." That's the good news.

The bad news is that, as of Blazor 0.8.0.0, no further upgrades to Blazor are available for Visual Studio 2017. If you want to continue to work with Blazor, you're going to need Visual Studio 2019 Preview (did I mention that this technology is "experimental"?).

It took me three or four tries before I got Visual Studio 2019 up and running with Blazor. My first couple of tries resulted in a version of Visual Studio that only had templates for Blazor applications and then created projects that wouldn't run. The order of operations that (eventually) worked for me was:

1. Download and install Visual studio 2019 Preview
2. Restart the computer
3. Download and install .NET Core 3.0. This adds (among other things) a Razor Components template ("Blazor on the server")
4. Download and install Blazor 0.8.0.0. This adds two new client-side Blazor project templates.

There are some known problems, and you should check out the Known Issues section here.

Download Woes
The fourth major change that stood out for me requires some explanation before discussing why I think it's valuable. Bear with me, here -- I have a point and I am getting to it.

This story begins with the change that didn't happen: There's no major reduction in the size of the Blazor client-side runtime in this release. The Blazor download remains at about 2MB (it's a complete .NET runtime, after all). When you compare this to Angular 2's download size (minified and gzipped), which hovers in the 100KB to 400KB area, this is an issue.

You can mitigate that cost by, for example, always pulling the Blazor runtime from a Content Delivery Network. With this strategy users only pay for the download the first time their browser encounters Blazor in a session (and, really, how often does anyone shut down their browser?). Caching the Blazor runtime somewhere close to the user (that is, in a proxy server) can also help.

Neither of these strategies solve the problem, of course: They just move it around. Fundamentally you're hoping that, by the time a user gets to your Blazor-enabled site, the user has paid the download cost ... just on someone else's site. However, the user is still paying for the download and, if you have a site that's already teetering on the edge of "not really loading fast enough," this could be a deal breaker.

I'm getting closer to my point here: Hang tough.

There are strategies that the Blazor team is pursuing to get Blazor down to a 1MB download. One approach is smarter linking so that only the components that the application uses are actually downloaded (the Xamarin team does a similar thing to minimize the footprint of applications on smartphones).

Another strategy is Ahead of Time complication (AoT). Right now, Blazor downloads .NET assemblies in IL and then compiles them into the byte code used on the browser. AoT would compile directly into the byte code during the compile process. This would probably reduce download size -- the initial Blazor runtime, fully compiled to byte code, took up only 60KB, well within the range of Angular 2. Since then, Blazor has moved to a different runtime which is "significantly larger" (to quote Microsoft) but the Blazor team thinks that size could be reduced through clever linking ... and AoT.

It seems pretty clear to me that AoT holds the most promise for significantly shrinking the Blazor runtime download size. But, it also seems clear to me, it would make debugging Blazor applications more difficult.

Fallout
Which leads (finally) to what I think is the other major improvement in the 0.8.0.0 release: Microsoft has made it easier to convert a project from "Blazor Running On the Server and Communicating with the Client Using Signal R" (Razor Components) to Blazor "running on the client" (Blazor).

With this change you could start building a project in Razor Components where (a) you don't care about download size because you're running on the server and (b) you're guaranteed the full debugging support that you take for granted right now. Then, when you're ready to move to production, you could convert to Blazor-on-the client with AoT.

Right now, it's not a trivial change (about six steps), but most of the changes are in your project's Startup class. The changes in the Startup class can be automated by leveraging the IHostingEnvironment object, which lets you check whether you're running in Production, Staging or Test and invoke the right code. Automating the other changes (updating the Program class, changing a tag in an HTML file and relocating the wwwroot folder) are more ... problematic. If the Blazor team can further reduce the friction in this conversion, this might give developers the best of both worlds in development and production.

So, with 0.8.0.0, the future isn't now, at least not yet. But it is closer.