Web developers

Angular or Blazor? Decision support for web developers

With Blazor, Microsoft was the last of the big players to enter the market for single page application frameworks. There, Blazor rivals long-established top dogs like Google’s Angular. This article aims to clarify which Angular and Blazor target groups are interesting.

In March 2018, Microsoft introduced Blazor, an experiment initiated by Steve Sanderson to bring .NET (again) back to the browser: Instead of JavaScript, developers can use C # and the Razor model language to develop web applications. With this, Blazor ties into ASP.NET MVC implemented on the server side.

Blazor is not just Blazor

First of all, we need to differentiate the two versions of Blazor: first there is the server-side Blazor Server. Application status is managed by the server, user interactions lead to communication with the server through SignalR, and HTML fragments are also exchanged through it. If a particularly large number of users are using the application at the same time, the server becomes a bottleneck. Slow connection results in poor user interface responsiveness.

In contrast, there is Blazor WebAssembly. Here the application, including the .NET runtime, is run entirely on the client side in the browser. In the simplest case, all you need is a static web server; the browser must support 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 start. Blazor Server is more of a stopgap solution.

WebAssembly brings many languages ​​to the web

WebAssembly (Wasm) is a bytecode for the Web intended to supplement JavaScript. The great advantage of Wasm over human readable JavaScript is that the code does not need to be parsed or interpreted. Program code written in other languages ​​(eg 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. The WebAssembly code is executed by the same engine that powers JavaScript. Therefore, the execution performance of Wasm code is not necessarily better than that of JavaScript applications (see also: Is WebAssembly’s magical performance pixie dust?). The WebAssembly code is also subjected to the same sandbox as JavaScript. This means that it is not possible to call native interfaces, only those for which there are suitable APIs on the web.

In order to run Blazor applications in the web browser, the .NET runtime environment is first downloaded and started in Wasm. Then the appropriate dynamic link library (DLL) is obtained with the .NET assembly and executed at runtime (just in time, from .NET 6, early compilation should be possible).

WebAssembly is standardized and has been supported by the four major cross-platform browsers Firefox, Edge, Safari, and Chrome for some time. This is how Blazor differentiates itself from Silverlight, the long-standing, proprietary, plug-in browser-based approach to 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 previous AngularJS framework, which was first released in 2009. This, in turn, was created based on experience implementing 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 reach of HTML with a template syntax. 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 apps.

Arguments for Blazor

Blazor is particularly interesting for teams who have knowledge of .NET and C #, but who are less experienced in handling JavaScript and are unable or unwilling to acquire knowledge in this area: A big advantage in using Blazor is that existing source code can potentially be taken over the web. Previous investments in a code base are thus retained.

As stated above, this is only possible if the functions and interfaces used are available in the web browser, i.e. they can be implemented in JavaScript: Random access to the file system or device interfaces is also not possible with WebAssembly. Additionally, C # code can be shared between server and client, like validation logic. Well-known component manufacturers also offer components suitable for Blazor; these can even be included in existing subscriptions and can also be simply used.

Arguments for angular

Angular is much older and therefore more mature than Blazor. Many features that Angular has provided for a long time and that work robustly there must first be provided by Blazor: Lazy loading of application components was only added to Blazor with .NET 5, for example. The other features are not yet available. Angular is at the forefront, for example, with advance compilation, which guarantees significantly smaller package sizes, or with live or hot reload. Here, the application is automatically reloaded after a change in the source code, which greatly increases the productivity of developers. Both are not expected to be submitted in Blazor until .NET 6 in November of this year. Since Angular apps are translated to JavaScript before being executed in the browser, these apps get by without heavy execution: a simple hello world app is only 170 kilobytes in Angular, while Blazor apps start with a 2 megabyte file size. JavaScript-based browser interfaces can be called directly in Angular, while Blazor requires an appropriate NuGet package or the use of the Interoperability Bridge.

Conclusion

Blazor is ideal for developers who have knowledge or existing code in the .NET environment who cannot move to a different technology stack and who can tolerate larger bundle sizes. It’s important that Blazor isn’t a magical .NET-to-the-web translation machine: Blazor developers aren’t immune to HTML, CSS, REST APIs, CORS, or operating models in cloud, so it will certainly come into contact with the web. technologies give.

TypeScript-based Angular may even be of interest to .NET developers: Anders Hejlsberg is the same language designer who is responsible for TypeScript as he is for C #. The two languages ​​are often influenced by each other and are syntactically very similar. The framework has been proven successful for years and due to its widespread use at Google itself further development should be assured for years to come. Developers without .NET experience 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 on all platforms.

Disclaimer: This article is generated from the feed and not edited by our team.