With Blazor, Microsoft was the last of the big players to penetrate the market for single-page app frameworks. There Blazor competes against long-established top dogs like Google’s Angular. This article aims to clarify which target groups Angular and Blazor are of interest.
In March 2018 Microsoft presented Blazor, an experiment initiated by Steve Sanderson to bring .NET (back) into the browser: Instead of JavaScript, developers can use C # and the Razor template language to develop web applications. With this, Blazor ties in with the ASP.NET MVC implemented on the server side.
Blazor is not just Blazor
First we have to differentiate between the two flavors of Blazor: First there is the server-side Blazor Server. The status of the application is managed by the server, user interactions lead to communication with the server via SignalR, and HTML fragments are also exchanged via it. If a particularly large number of users use the application at the same time, the server becomes a bottleneck. A slow connection results in poor user interface responsiveness.
In contrast, there is Blazor WebAssembly. Here the application including the .NET runtime is executed completely on the client side in the browser. In the simplest case, all you need is a static web server; the browser must support the WebAssembly technology. Once loaded, the application can also be run offline. When Blazor is mentioned in this article, it always refers to the WebAssembly variant, which was also the target expansion stage planned from the outset. Blazor Server is more of an interim solution.
WebAssembly brings many languages to the web
WebAssembly (Wasm) is a bytecode for the web that is intended to complement JavaScript. The great advantage of Wasm over human-readable JavaScript is that the code does not have to be parsed or interpreted. Program code written in other languages (e.g. Rust, C #, Java) can be compiled according to Wasm and then executed in the web browser.
The technology is not intended to replace JavaScript, but rather to supplement it for special applications. WebAssembly code is executed by the same engine that powers JavaScript. Therefore, the runtime performance of Wasm code is not necessarily better than that of JavaScript applications (see also: Is WebAssembly magic performance pixie dust?). WebAssembly code is also subject to the same sandbox as JavaScript. This means that it is not possible to call any native interfaces, but only those for which there are suitable APIs on the web.
In order to run Blazor apps in the web browser, the .NET runtime is first downloaded and started in Wasm. Next, the appropriate dynamic link library (DLL) is obtained with the .NET assembly and executed in runtime (just in time, from .NET 6 onwards, ahead-of-time compilation should be possible).
WebAssembly is standardized and has been supported by the four major evergreen browsers Firefox, Edge, Safari and Chrome cross-platform for some time. This is how Blazor differentiates itself from Silverlight, the long-discontinued, proprietary and browser plug-in-based approach of running .NET applications in the browser.
Angular: The top dog among SPA frameworks
Angular was released by Google in 2016. It is based on Google’s experience with the predecessor framework AngularJS, which was first published in 2009. This, in turn, was created on the basis of experience with the implementation of large web applications such as Gmail. Angular is the most widely used framework at Google itself.
The variant released from 2016 is based on the TypeScript language. Similar to Razor, Angular extends the scope of the HTML language with a template syntax. The TypeScript source files must be translated to JavaScript before they can be executed in the browser. JavaScript, in turn, can be executed directly in the browser, which is why Angular apps are much closer to the web than Blazor applications.
Arguments for Blazor
Blazor is particularly interesting for teams who have knowledge of .NET and C #, but are less experienced in handling JavaScript and who cannot or do not want to build up any knowledge in this area: A big advantage in using Blazor is that existing source code can eventually be taken onto the web. Previous investments in a code base are thus retained.
As noted above, this is only possible if the functions and interfaces used are available in the web browser, i.e. can be implemented in JavaScript: Random access to the file system or device interfaces is also not possible with WebAssembly. Furthermore, C # code can be shared between server and client, such as validation logic. The well-known component manufacturers also offer suitable components for Blazor; these may even be included in existing subscriptions and can simply be used as well.
Arguments for Angular
Angular is much older and therefore more mature than Blazor. Many features that Angular has been providing for a long time and that work robustly there must first be delivered by Blazor: Lazy loading of application components was only added to Blazor with .NET 5, for example. Other features are not yet available. Angular is at the forefront, for example, with ahead-of-time compilation, which ensures significantly smaller bundle sizes, or with live or hot reloading. Here the application is automatically reloaded after a change in the source code, which significantly increases developer productivity. Both should not be submitted in Blazor until .NET 6 in November of this year. Since Angular applications are translated to JavaScript before they are executed in the browser, these apps get by without heavy runtime: A simple hello world application is just 170 kilobytes in size in Angular, while Blazor applications start with a file size of 2 megabytes. JavaScript-based browser interfaces can be called directly in Angular, whereas Blazor requires a suitable NuGet package or the use of the interop bridge.
Conclusion
Blazor is ideal for developers who have knowledge or existing code in the .NET environment for whom switching to a different technology stack is out of the question and who can tolerate larger bundle sizes. It is important that Blazor is not a magical .NET-to-web translation machine: Blazor developers are also not spared dealing with HTML, CSS, REST APIs, CORS or operating models in the cloud, so it will definitely come into contact with web technologies give.
Angular based on TypeScript can even be of interest to .NET developers: Anders Hejlsberg is the same language designer who is responsible for TypeScript as for C #. Both languages often influence each other and are syntactically very similar. The framework has proven itself in use for years and due to the widespread use at Google itself, further development should be ensured for years to come. Developers without a .NET background are probably better off with Angular.
Ultimately, it should be noted that there is no functional difference between the two approaches: The same range of functions can be implemented in Angular as in Blazor and implemented across platforms.
