Working with Blazor

There are many ways to build modern web applications. Today I would like to share some insights on working with Blazor, which is a viable web framework for teams that primarily work with C# and ASP.NET. In our team, specifically, I am the only Angular/JavaScript guy and responsible for a number of front-end web applications written with Angular. We are now choosing between Angular and Blazor for a new major version of our main software product, and it’s a tight race between the two.

Although Angular is the more mature framework with more contributors and more web apps using it, Blazor has one major advantage. In our small team of three developers, we have two completely different tech stacks:

  1. .NET/NuGet with C# for building web services, windows clients and console jobs.
  2. node.js/npm with Angular for building web apps

These are two worlds, with respect to programming, development environment, package infrastructure and build environment. And it is a major mental shift to switch from one to the other. So why not choosing one tech stack and making it easier to work on different parts of our ecosystem? That seems enticing.

What I have done in the last couple of weeks, is building a prototype with Blazor to get a feeling for it. It is important to note that Blazor saw some major improvments with ASP.NET Core 8, making it a full-stack web framework. It supports a number of render modes:

  1. Static Server (SSR)
  2. Interactive Server (using SignalR)
  3. Interactive WebAssembly (Client)
  4. Interactive Auto

Coming from Angular and having done some Razor templating back in 2010-14 when working for comparis.ch, I felt at home with Blazor right from the start. The general concepts like templates, event handlers and components/services were easy to get into. Routing works differently, you can declare it within the page with the @page directive.

@page "/my/route"

<PageTitle>Routing</PageTitle>

<h1>Routing Example</h1>

<p>
    This page is reached at <code>/my/route</code>.
</p>

My hope was to use mainly the InteractiveServer render mode. Our application does not have millions of users at the same time, so the web server should be able to serve the content to a few hundret users. During development, everything looked find with satisfactory reaction times. But rolling out on a IIS web server and activating WebSockets there did not lead to decent reaction times. Most of the time the app reacts pretty quickly, but sometimes, the WebSocket connection is interrupted and it takes seconds before a drop-down opens.

I have to investigate this deeper. Could be a server issue, we will try a different deployment model, e.g. with containers. But it could also mean that we need the InteractiveWebAssembly render mode to run the application entirely on the client.

angular asp.net blazor programming