Blazor to the rescue

What is Blazor?

To answer this question, we first need to understand how Blazor works. The name gives us the first clue here (source: devblogs):

Browser + Razor = Blazor!

Blazor is a new open source-based web framework from Microsoft. As with other web frameworks, Blazor uses HTML and CSS to render a web application – the difference being that executable program code is executed with C# and the Razor syntax instead of with JavaScript. Anyone who already has experience of the Razor syntax from ASP.NET Razor Pages will therefore have no problem quickly finding their way around Blazor.

Blazor has a number of variants. The two most important are:

• Blazor Server
• Blazor WebAssembly

In addition, there are other variants such as Blazor Electron (for desktop platforms) and Mobile Blazor Bindings (for mobile platforms). However, these are not yet fully developed and will therefore not be explained in further detail in this article.

Blazor Server

Blazor Server was released on 23 September 2019 as part of ASP.NET Core 3.0 RTM. The functionality is very similar to ASP.NET MVC and ASP.NET Razor Pages, but with some differences. For example, the web application is rendered as a Single Page Application (SPA) on the server. Only JavaScript and markup are sent to the client and the data and user input are continuously exchanged between client and server via SignalR. A permanent connection between client and server is necessary for this. The web page does not flicker during round trips, however, as is familiar from other server-side rendering frameworks.

Blazor Server offers Long-Term Support (LTS) with .NET Core 3.1. The full .NET Core 3.x functionality and all resources can be used on the server, and none of the restrictions associated with a browser sandbox exist. The page generated on the server loads the application quickly onto the client, has a small download size and can be used on low-performance clients (ThinClient). Any browser in its more recent version can be used; even IE, provided that the communication capability has been reloaded via WebSockets using polyfills.
Blazor can score points in terms of security: The executable source code remains exclusively on the server and is not transmitted to the client. Authentication tokens for sessions also remain on the server.

There are also some disadvantages with Blazor Server, however, apart from the advantages. For example, every client browser instance ensures that the application state is cached on the server. As a result, the number of participants is effectively limited by the performance of the server – the application is not highly scalable. Because there is permanent communication with the server, Blazor cannot work offline and a considerable amount of network traffic arises. In the case of UI updates, noticeable delays can therefore result. Microsoft thus recommends a maximum network latency of no more than 250 milliseconds. An ASP.NET Core server must be available for the deployment.

The disadvantages mentioned are particularly evident in mobile applications where users are on the move and do not always have access to a stable and low-latency connection.

Blazor WebAssembly

In contrast to Blazor Server, the code for Blazor WebAssembly runs in the browser on the client and communicates with the server via a web API. As the name suggests, Blazor WebAssembly is based on WebAssembly (WASM for short). WASM is bytecode for executing native code in the web browser and is driven by major developers of browser engines (such as Mozilla, Google, Microsoft, Apple etc.) and standardised by W3C. The major advantage of WASM lies in its quick execution on the client: The code runs in the browser in a sandbox and manipulates the DOM in the browser via JavaScript. Thanks to WASM, an almost native performance is thus achieved. JavaScript does not disappear completely, but is merely supplemented. WASM runs with more recent versions of major browsers (see “Can I use” for details). Among others, Microsoft’s IE is not supported.

In the case of Blazor WebAssembly, the WebAssembly capability, the .NET runtime and the app-specific .NET code with the Razor components responsible for rendering are downloaded. Access to client peripherals (camera, microphone, etc.) is possible without JavaScript. In cases where there is no Blazor component for a device, native access is possible via JavaScript with JS interop. Every WebServer that offers Static File Deployment, such as a Content Delivery Network (CDN), can be used for hosting – which means that no ASP.NET Core-capable server is needed. As Progressive Web Apps (PWA), offline operation and local installation are not an issue. In addition, there are no waiting times with UI updates (zero latency). The application is highly scalable since the entire code runs on the clients.

Owing to the additional .NET assemblies and the WASM framework, the initial download is relatively large, which has a negative effect on the startup time of the application. With each subsequent execution, the browser cache shortens the waiting time. Mechanisms such as TreeShaking or Ahead-of-Time (AOT) compilation have been announced for the future, however, which should reduce the download size and waiting time. It remains to be seen just how effective these will be. The application code and, for example, authentication tokens are transmitted to the client. In contrast to Blazor Server, Blazor WebAssembly still does not offer Long-Term-Support (LTS).

Comparison of Blazor Server vs. Blazor WebAssembly

Users can naturally use the .NET Framework for both architectures. In addition:

• Users have access to the familiar ecosystem (tools, FX, lib, tests) – whether VisualStudio 2019, VS Code, VS for Mac, Rider or .NET CLI. Automated tests can be realised with familiar frameworks (xUnit, NUnit, MSTest etc.). TestHosts are recommended for stable E2E tests (Microsoft.AspNetCore.Components.Testing / MS experimental) or BUnit; other E2E test suites, such as Cypress, Ranorex and Selenium, can naturally also be used.
• Continuous debugging from the client to the server is possible.
• The same API model can be used on the client and server as a shared library, without needing to bother with a generator or converter.
• Blazor is optimised for rendering and user interaction. It is possible to take over existing code to some extent. However, if the architecture is not right or if intensive algorithmic tasks have to be solved, it is not advisable.

Comparison of Blazor WebAssembly vs. Blazor Server

Outlook

Microsoft has committed itself to Blazor Server and Blazor WebAssembly. Blazor WebAssembly joins the ranks as a direct competitor to the existing JavaScript SPAs (Angular, VueJS, React etc.). These web technologies have already been in use for a number of years. Blazor, on the other hand, is still in its infancy.

As indicated at the beginning of this article, efforts are also being made to offer Blazor on desktop and mobile platforms too. Especially in terms of LTS, Blazor WebAssembly is still some way off: The first LTS was only announced with .NET 6 and is expected to be released in November 2021.

An overview of how the Blazor community has driven the solution – and continues to drive it – is provided by awesome Blazor.

Conclusion

It remains to be seen how well applications developed with Blazor will perform in practice. We are in any case of the view that Blazor has a real opportunity to secure its place among the most popular web frameworks.
However, if a development team is satisfied with Angular, React etc., switching to Blazor is only recommended with certain reservations. We recommend Blazor primarily for .NET development teams, who do not want to or cannot leave their familiar development environment and are not in a position to invest in intensive training. Training in web, HTML, CSS, Responsive Design etc. is essential to succeed with Blazor.