Blazor: An alternative to Angular, React, etc.?

The range of frameworks for web applications is steadily growing. In addition to familiar solutions, such as Angular or React, there are a number of other JavaScript frameworks that can be used to develop web applications. A new solution was added to the range of web frameworks in 2018 with Microsoft Blazor. But what exactly is behind it? How does Blazor differ from other web frameworks? And: Is the switch worth it at all?

What is Blazor?

Blazor is an open source-based web framework from Microsoft which, like other web frameworks, uses HTML and CSS to render web applications. The difference: Unlike other frameworks, Blazor is not based on JavaScript, but on .NET and the Razor syntax. Programming is done in C#. A trusted ecosystem is therefore available to developers for implementing web applications, without the need for them to familiarise themselves additionally with JavaScript-based frameworks.

There are a number of different variants of Blazor. The most important – Blazor Server and Blazor WebAssembly – are briefly presented here:

Blazor WebAssembly: Applications are executed directly in the browser on a .NET runtime, which is based on WebAssembly. These applications operate in a similar way to frontend JavaScript frameworks, but are developed in C#. When navigating to a Blazor WebAssembly app, a query is issued to the web server, which responds with the .NET runtime environment together with WebAssembly and all required dependencies. Browser plugins or enhancements are not necessary. Because the runtime environment supports the .NET standard, existing .NET standard libraries can be used effortlessly with the Blazor WebAssembly application. This is executed purely on the client side – .NET is not required on the server.

Blazor Server: The components of the web applications are prepared on the server and not on the client side in the browser. When a request is sent to the server, it transmits an initial Document Object Model (DOM) – in other words a virtual twin of the browser content, which handles communication with the server. UI interactions such as clicks or text inputs, which take place in the browser, are sent to the server over a real-time connection (SignalR) and forwarded to the correct component instances. The components are rendered and the calculated UI DIV – a general container in HTML at block level for page elements – is sent back to the browser or DOM. The rendering in the web application is adapted.

Blazor WebAssembly vs. Blazor Server: Advantages and disadvantages

Since the code is executed locally in the browser in Blazor WebAssembly, the client resources can be exploited to the full, which significantly increases the performance. In addition, the load is moved from the server to the client, making the application scalable. A .NET dependency on the server side does not exist. The application is fully functional and can work offline on the client when downloaded. However, the browser also imposes limitations that can restrict the application. Moreover, suitable client hardware and software are needed so that applications can operate on Blazor WebAssembly. The download is larger and the applications have a longer loading time than with Blazor Server.

Blazor Server can exploit the possibilities of the server fully, including the use of all .NET-compatible APIs. In addition, thin clients are also supported effortlessly. Blazor Server applications also work for browsers that do not support WebAssembly and on devices with limited resources. The latency of the user interface on Blazor Server is high for this purpose, since any user interaction will potentially trigger communication with the server. Because the server therefore has to manage several client connections, the scalability of Blazor Server is a challenge for applications with a large number of users. There is no offline support: If the client connection fails, the app will no longer work. In addition, an ASP.NET server is required for deploying the application. Serverless deployment scenarios, such as via Content Delivery Networks, are not possible with Blazor Server.

Comparison of Angular, React and Blazor

To evaluate usage of Blazor, it is worth comparing the two web frameworks that are most widely used in Switzerland at present: Angular and React. Angular was published in 2010 and is now used – meanwhile as a TypeScript framework – by well-known companies such as Google or Microsoft. Robustness and compliance with standards are the focal points with Angular. It is therefore not possible with Angular, for example, to integrate arbitrary JavaScript libraries. The many functionalities and features that Angular offers are at the same time a disadvantage of the web framework: They have to be learned first before the framework can be properly appreciated. A certain familiarisation time is therefore unavoidable with Angular. While two major updates of the framework are released each year, switching from one major version to the next always involves some migration effort. Regular migrations therefore have to be expected in the case of projects with a longer development time.

Compared with Angular, React is not a TypeScript library, rather a pure JavaScript library. Among others, companies like Facebook or Uber use the framework. In contrast to Angular, different JavaScript libraries can be incorporated with React – which allows great flexibility in the development and implementation of web applications. Updates are also released at short intervals for React, but the version changes are significantly smaller than with Angular.

Blazor focuses primarily on .NET developers, so that they can reuse the existing knowledge in .NET and C# for developing web applications. As a comparatively young framework, Blazor is still experiencing some teething problems, though the community is constantly trying to resolve these. Long-Term Support (LTS) of three years is already available for Blazor Server for even-numbered major versions. Intermediate versions or odd-numbered major versions come with 18 months support. A corresponding support model is also planned for Blazor WebAssembly. Blazor has recently been added to the new .NET platform. This is currently Version .NET 5, .NET 6 will be released in November this year. Among the most important innovations for WebAssembly and Blazor Server are:

• Hot Reload: Only data that has been changed is updated without altering the status of the app (no build-run cycle).
• Ahead-of-Time compilation for Blazor WebAssembly: Accelerates the execution of Blazer code in the browser.
• Error boundary: Errors within the application are intercepted without the entire application being brought to a standstill. Instead, a fallback UI is used.

Conclusion: Is Blazor worthwhile?

The basic knowledge that frontend developers need to have is the same for all three frameworks: Knowledge of HTML5 is needed and of how JavaScript and CSS work. As soon as more demanding websites or progressive web applications need to be developed, knowledge of Service Workers is also required. Developers also need to be familiar with areas like Web Sockets, Ajax and others when they venture into web applications. This basic knowledge must be available in order to tackle one of these frameworks.

The advantage of Blazor: It is limited to the familiar Microsoft ecosystem and functionalities can be implemented with C#. For .NET teams, Blazor WebAssembly in particular offers an ideal entry point to single-page applications, because the learning curve is significantly less steep than with JavaScript frameworks. With a stable network connection – for example on the Intranet – and a known number of users, Blazor Server applications can be useful in particular – e.g. for a monitoring cockpit. However, where a web application project has already been initiated with a different framework, then switching scarcely makes sense. Blazor is also less suitable for mobile applications owing to the permanent connection to the server (Blazor Server) and the larger download sizes (Blazor WebAssembly).