I wrote about Blazor some time ago. Blazor is really cool in my opinion and, in a certain way, the future of web development (even if not in the form we might think of nowadays). It is a single-page web app framework built on .NET Core that runs in the browser with WebAssembly. The overview I made earlier is still valid so you might check it out. In this article however I want to offer a quick overview of a feature called Razor Components or server-side Blazor.

Why 2 names?

Server-side Blazor was a really big feature of the 0.5.0 Blazor release. Blazor is principally a client-side web framework intended to run in a browser where the component logic and DOM interactions all happen in the same process. However, Blazor was built to be flexible enough to handle scenarios where the Blazor app runs apart from the rendering process. For example, you might run Blazor in a Web Worker thread so that it runs separately from the UI thread. Events would get pushed from the UI thread to the Blazor worker thread, and Blazor would push UI updates to the UI thread as needed.

In the 0.6.0 release earlier this month, the development team wen one step further and integrated server-side Blazor with SignalR alongside with a new feature that enables developers to author templated components. Conceptually we can think about these components as Angular components (although everything is really different). Since this feature seems to work well enough, it will be part of the .Net Core 3.0 release, known as “Razor Components”. Basically server-side Blazor evolved in to what will be called Razor Components in .Net Core 3.0

How do Razor Components work?

When you make the initial request your browser will download an index.html file and a small javascript file called blazor.server.js. Blazor then establishes a connection between your browser and the server using SignalR.

The server will execute the component logic server side producing HTML. This is then compared, on the server, to a snap-shot of the DOM currently on the client. From this comparison the changes required to make the DOMs match are produced. These changes are then packaged up and sent down to the browser via the SignalR connection. Once at the browser the HTML changes are unpackaged and applied to the DOM.

You can have of course several such components and starting with Blazor 0.6.0 you can also pass parameters between them.

Benefits

From my point of view the coolest benefit resides in the fact that such an application will have a SPA (single-page application) look and feel without technically being a single page application. On the other hand, comparing this to the full Blazor experience via WebAssembly the overall download sized are substantially smaller since you don’t have to actually ship the Mono runtime and all necessary dll files to the browser.

Challenges

Server-side Blazor (or Razor components) looks great at a first glance. However, there are some trade-offs that developers need to to be aware of.

Since Razor Components rely on SignalR, everything will work as a charm as long as the web sockets connection is alive. If connectivity is lost, then the application won’t react as expected. This is not something totally unexpected since all MVC applications have this kind of challenge. However, developers coming to Blazor with more experience on Angular for instance will find this as something unnatural. What this means in plain text is that developers need to find a way to handle application state, if needed. For now there is no direct support for this in server-side Blazor, but the team is working on it so I would expect to have some basic support for this scenario when Razor Components will be shipped in .Net Core 3.0.

The other challenge developers need to be aware of is latency. While SignalR is very efficient there is still a lot of chattiness with the server-side implementation. This can lead to a slightly sluggish feel at times with server-side Blazor (Razor Components) apps. Every time a user interacts with your application a round trip has to be made to the server to process the interaction. This is also where scalability comes in place. The server has to manage the connections to every client that is currently using the application. Since Blazor is for now an experimental project no conclusive tests on heavy load applications were made. However, I would also expect that until the .Net Core 3.0 release the Blazor team will provide also insights in this regard.