Blazor now runs on a server: What you should know

It’s a year or so since Microsoft unveiled Blazor, its tool for running .Net code in the browser. It’s been an eventful year with several releases, each adding more and more code compatibility. Now described as “full-stack web development with C#,” Blazor runs on both clients and servers.

Built on top the open standard WebAssembly platform, Blazor implements a .Net runtime in the browser that’s optimized for single page web applications. With a browser version based on the familiar Mono, your code is compiled on the fly, driving HTML and JavaScript page components. While Microsoft still classifies Blazor as experimental, a series of recent announcements make it clear that it’s nearly ready for prime time.

Blazor on the server

While WebAssembly Blazor is still some distance from release, Microsoft is accelerating the release of the server-side version of the technology, as part of ASP.Net Core 3.0, under the name Razor Components. Don’t be fooled by the name change: This will be the familiar Blazor Razor syntax, with your code now running on a server, giving you the option of developing and using shared components across all your web applications.

Releasing a server-side version is a sensible decision, because not all browsers fully support WebAssembly. Instead of running in your browser, your Blazor code runs in ASP.Net Core, using SignalR to send events to and from JavaScript code in your browser.

It’s going to be a while before ASP.Net Core 3.0 gets released, but you can get started with server-side Blazor now to understand how to use it in your applications. You can also develop your first server-side Blazor components, using Razor syntax markup. The learning curve should be quite short, because there’s a lot of similarity between Blazor and the original ASP.Net approach to developing web apps, linking markup to code in the same document.

With Blazor on the server, you still get to write your web application in C#. Creating a new server-side Blazor application sets up an ASP.Net Core template for your code, with a SignalR endpoint for clients.

Why use Blazor on the server

There are benefits to using Blazor on the server. Because it’s a full .Net app, it’s going to be precompiled and won’t require compiling in WebAssembly every time you load it. That should make things faster for your users, both in terms of application and page-load times. Developers get other advantages, too: You get direct access to it for debugging, using Visual Studio’s remote debugger on running ASP.Net Core code. You can also target a wider range of clients, including older mobile devices that don’t support WebAssembly. And using SignalR as an endpoint means you also have the option of delivering native clients as well as web applications.

Not everything in the Blazor garden is rosy. Browser-hosted WebAssembly applications can run offline, or as part of a progressive web app. That’s not the case with server-side Blazor, because you need to have a SignalR connection with your server. That connection will also be subject to network latency, making a server-side Blazor application significantly slower than one running in WebAssembly.

There are other issues with this approach that do require some thought: At its heart, Blazor is a tool for building stateless single page applications, and while a persistent SignalR connection should handle state for you, there’s always a risk that you could lose connectivity with clients. You’ll need to build an appropriate mechanism to restore application state in the event of a failed network connection, something that’s essential if you’re expecting mobile clients to use your application.

There’s a definite trade-off between using Blazor in WebAssembly and on the server. While running in WebAssembly means you can deliver code from anywhere and don’t need to rely on ASP.Net Core, that scenario is not supported and probably won’t be for some time. Server-side Blazor requires an ASP.Net Core server, so you need to consider how you might want to deploy one or more if you want to take this approach. One advantage of using ASP.Net Core over other server technologies is that it runs on Linux and on Windows Nano Server, making it easy to containerize, manage, and scale with Kubernetes and with tools like Azure Service Fabric Mesh.

Adding third-party components to Blazor

There’s already support from UI component vendors, with Progress recently announcing that it’s adding Blazor UI components to its Telerik UI framework. Building on its familiar Kendo UI tools, Telerik UI for Blazor is an early beta release, one that supports the full Blazor component model, mixing markup and code in a single file. It’s initially a small set of components, with a data grid, a tab set, and customizable buttons.

Progress is targeting its Blazor components at its server-side implementation. Available as a NuGet package, using the Kendo namespace, it’s easy to add to your Blazor code, with support for data binding and themes. It’s currently free, and it will be updated as Microsoft updates its own Blazor implementations. While server-side Blazor support is logical, because it uses the same runtimes as the WebAssembly version, you can still use the Telerik components in your WebAssembly apps.

Blazor’s transition from EdgeHTML to Chrome

With a server-side future assured, what’s next for Blazor in the browser? Despite a big shift from EdgeHTML and Chakra to Chromium, Microsoft’s Edge browser changes shouldn’t affect Blazor significantly; WebAssembly is a cross-browser technology that’s supported by all the major web platforms. Blazor already runs in Chrome, and the Chrome remote debugging tools are a useful part of ensuring your code works well.

It’s actually a change that’s likely to make it easier to take the client-side Blazor to production standard. Chromium’s WebAssembly features are already shipping in Google’s Chrome, so it should be relatively easy for Microsoft to bring them into its Edge implementation. Chromium’s focus on getting a good C and C++ implementation in WebAssembly makes it easy for a .Net runtime to drop into Chromium. If I were to make a guess, I’d suggest the resulting changes in Edge may make it easier for Microsoft to take Blazor from experimental to preproduction, and then to release state.

Blazor may have begun life as an experiment, but it’s rapidly becoming an integral part of ASP.Net Core. Bringing a component UI model to web applications should reduce the risk of redesigning a grid control with every new app, and having component vendors involved with the project will make it easier for developer to justify using Blazor in next generation web apps because they’ll be able to build on existing support relationships and existing skills.