How does Blazor rate compared to Angular?

What are the advantages of Blazor WebAssembly? Full-stack web frontend and backend developers are difficult to find on the market, especially in the .NET area. And as already described in our earlier article on web architectures, there is a certain learning curve associated with developing modern web applications. .NET developers who are not so well versed in the world of JavaScript or TypeScript, which is a prerequisite for JavaScript frameworks, require intensive training in particular. This is precisely where Microsoft wants to score points with Blazor WebAssembly. The greatest advantage is that .NET developers remain in their own ecosystem and do not need to learn any tools that are new to them, such as npm, Jasmin, Karma, etc., rather can continue to use their existing tools such as Visual Studio and NuGet. In general, nothing much should change in terms of the familiar way of working. Blazor WebAssembly can be examined at runtime using a debugger, just like other .NET applications.

But is this new framework a real alternative? Although Blazor WebAssembly is still relatively new, it already offers some useful functions, including:

• Globalization & localization: support for multilingualism and regional settings, such as display of date and time, numbers, currencies, etc.
• Debugging
• IL trimming (the counterpart to “treeshaking” in Angular) to remove unneeded program code prior to deployment
• Offline capability as a Progressive Web App (PWA)
• Security functions for user authentication and authorisation
• Uploading files

Angular already has a major head start of several years here however; the first version of Angular (AngularJS) was released in October 2010. Angular has built up a vast repertoire of functions in this time. In addition to the functions already mentioned, it offers some others that are still not provided in Blazor:

In particular, our Angular colleagues criticise the limited possibilities for optimising performance. This includes the reduction in app size and improvement in startup time using Ahead-of-Time (AOT) compilation, which are still lacking in Blazor. To understand why these functions are so important, we will take a look at the following direct comparison. We will take the respective Tutorial Apps in both frameworks as a baseline.

Comparison 1: Reduction in app size

Both apps are PWAs. This means that all data required for execution is transmitted to the client browser when the app starts up. In mobile scenarios, in particular, it is important to keep the file size as small as possible in order not to lose acceptance among users. Unlike Blazor, Angular supports Lazy Loading. This means that not all application data is transferred when the app is started, rather only the data that is needed for immediate execution.
Both frameworks offer the possibility to compress program data additionally prior to transmission. If we now compare the technologies in relation to the file size transmitted when the app is started, a very different picture emerges.

It is striking that the program files are considerably smaller in Angular. Angular is also considerably more efficient in terms of compression. In Angular, we were able to reduce the app size from an original size of 4.7 MB to 1 MB using optimisation mechanisms. With Blazor, on the other hand, we only managed to reduce the original size from 10 MB to 6.4 MB with the tools currently available.

Comparison 2: Startup time

Unlike just-in-time compilation (JIT), where all program files are first transferred from the server to the client and prepared in the client browser, with AOT compilation, the program files are already prepared for execution before they are transferred. As a result, an app can be executed directly in the client browser following downloading. If an app has already been invoked once by a client, the program files are buffered in the browser cache. This reduces the startup time of the app considerably from the second invocation, as can be seen in the next figure.

In the case of Angular, the major advantage of AOT compilation compared to JIT compilation lies, in our opinion, in the startup time of an app. Unfortunately, this feature is lacking in Blazor WebAssembly. It is all the more regrettable that AOT compilation was not released in November 2020 as originally announced, rather was postponed due to technical implementation difficulties.

Short life span of SPA frameworks

The life span of SPA frameworks is relatively short in relation to the major versions. A web frontend application is considered outdated after just one or two years. For example, Angular 8 was released on 28 May 2019 and Long-Term Support (LTS) ends this year on 28 November. There have already been two Angular major version releases this year: Angular 9 was introduced onto the market on 6 February and Angular 10 on 24 June.

Source: angular.io

The relatively short life span shows that SPA frameworks come and go. It is therefore all the more important to be aware of this and not fall into the trap of planning to develop a web application for the next 10 years, since the framework used may already be obsolete by the time the app is released.

There is no appeal in having to redevelop self-written frontend components again after just a year. That’s why some development teams write their frontend components as Web Components. This not only allows them to switch risk-free to a major framework version, but also potentially to a different SPA framework. Blazor WebAssembly also supports Web Components, which would allow existing frontend components to be reused or transferred.

Closing words

Microsoft is working intensively on Blazor WebAssembly. It offers everything needed to develop modern SPAs. But the head start that established SPA frameworks like Angular have is already considerable. Some time is still needed until Blazor can fully compete at this level. Announced features like AOT compilation, which were still on the list for the next release a month ago, are being pushed back due to technical implementation difficulties.

All in all, we are of the opinion that Blazor WebAssembly is definitely an option for small projects. However, we advise waiting another while before using it for larger web applications. At least until Blazor WebAssembly gets a LTS release (this will probably be the case next November).