The Practical Client

Blazor on the Server: The Good and the Unfortunate

Blazor on the Server is coming with .NET Core Version 3.0 in the second half of 2019. Here's what Peter thinks of that (and he's not completely happy).

• By Peter Vogel
• 04/30/2019

Blazor as "C# running on the client" has had its release date moved to "sometime after .NET Core 3.0.0." But what is definitely coming is .NET Core Version 3.0.0, sometime in the second half of 2019. You can even start playing with it now, using the ASP.NET Core 3.0 preview. That matters because ASP.NET Core 3.0 delivers "Blazor on the Server" (hereafter BotS), briefly known as "Razor Components."

The Good
If you're wondering what the difference is between Blazor and BotS ... well, from "the code on the ground" point of view, not much. It's pretty much impossible, just by looking at the code in a page, to tell whether you're working with Blazor-on-the-Client or Blazor-on-the-Server. The primary difference between the two -- where your C# code executes -- is hidden from you.

With BotS, SignalR automatically connects activities in the browser with your C# code executing on the server. That SignalR support obviously makes Blazor solutions less scalable than other Web technologies because of SignalR's need to maintain WebSocket connections between the client and the server. However, that scalability issue may not be as much of a limitation as you might think.

What BotS does do, however, is "normalize" a lot of the ad hoc ways that have been needed when working Blazor in previous releases. BotS components are, for example, just another part of an ASP.NET Core project and play well beside other ASP.NET Core technologies like Razor Pages, View Components and good old Controllers+Views. Visual Studio also now includes templates that allow you to create a single project that supports BotS without having to generate additional "support projects." Blazor-enabled pages also now have their own file extension (.razor) and their own spot in an ASP.NET Core project's structure (a folder called Components).

This gives you the opportunity to substantially reduce the size of your toolkit by leveraging C# code for client-side activities. You won't be able to completely give up JavaScript though. You'll still need some JavaScript code, for example, when you need to access the various HTML5 APIs (though packages like Blazor.Geolocation may render that unnecessary, also). At that point, you'll take advantage of Blazor's ability to integrate C# code with JavaScript.

The Unfortunate
But, for me, the disappointing part of the current version of BotS is that they "play well beside" rather than "play well with" the other ASP.NET Core technologies. I can't (or haven't figured out how to) use Blazor in a View generated from a Controller or to how to integrate Blazor into a Razor Page, for example (and I really, really like Razor Pages).

In addition, BotS have little (or no) server-side support. A Razor Component has no Model property that can accept data created in a Controller (as a View does) and no associated class file to initialize a page during the initial GET request (as a Razor Page does). Even the ViewBag isn't currently supported in a Razor View.

There's nothing stopping you, of course, from putting a code block at the start of your Razor page, like this:

@{
  string initialvalue;
  initialValue = "Hello, World";
}

But there's no way to pass this code any initial data. This means that there doesn't appear to be any obvious way to initialize a page on the server before sending it to the user. More critically, there's no way to way to automate testing the server-side code you insert into a Razor Page. Here's a place where an MVVM model might help, though it would be limited to sharing data through the Session and Cache objects.

The typical pattern for BotS, then, is that a user will request a Razor Component and the page will download to the browser. At that point, you'll probably have your Blazor code start making Web Servce requests back to the server to get the data to populate the page. That's not the end of the world and, if you're already building fully Ajax-enabled pages, this may be exactly the way your pages already work.

If that's the scenario you're using (or want to adopt), then BotS will let you do that with better compile-time checking than you'll ever get with JavaScript. I may be (currently) disappointed with the state of Blazor but BotS are still an opportunity to reduce the size of your toolkit in order to focus on .NET.