Blazor vs Angular front end considerations for .NET stack

Blazor


A primary benefit of NET Blazor development is leveraging existing .NET knowledge and skills for web front end, windows, and mobile app development.

A popular tech stack for enterprises who have committed to Microsoft Windows as their development platform of choice is the use of .NET ASP Framework/core along with Angular as the front end for application development. It may seem like a no-brainer to choose Blazor over Angular when choosing frontend development however it is important to note there are some significant differences beyond obvious language and tooling aspects.

  1. Runtime: Angular applications run directly in the JavaScript engine of the browser. JavaScript is a dynamic, interpreted language, and all modern browsers have a built-in JavaScript engine to execute it. When an Angular application runs, the Angular framework, along with your application code, is downloaded and executed in the browser’s JavaScript engine.

    On the other hand, Blazor WebAssembly apps run in a WebAssembly-based .NET runtime. WebAssembly (often abbreviated as wasm) is a binary instruction format for a stack-based virtual machine. It’s designed as a portable target for the compilation of high-level languages like C, C++, and Rust, enabling deployment on the web for client and server applications. When a Blazor WebAssembly application runs, the .NET runtime, the Blazor framework, and your application code are downloaded and executed in the WebAssembly runtime in the browser.

  2. Interoperability: Angular has direct access to browser APIs via JavaScript. This means you can use any browser API directly from your Angular code because it’s all JavaScript. You can manipulate the DOM, use the Fetch API for HTTP requests, use WebSockets, and more, all directly from your Angular code.

    Blazor WebAssembly, on the other hand, needs to use JavaScript interop to access browser APIs not abstracted by .NET. While .NET provides many abstractions for things like HTTP requests (HttpClient) and timers (System.Timers.Timer), there are many browser APIs that are not directly available in .NET. To use these APIs, Blazor provides a way to interoperate with JavaScript. You can write JavaScript code and call it from your C# code, and vice versa. This allows you to do anything you could do in a JavaScript application, but it does add a layer of complexity compared to Angular’s direct access to browser APIs.

Other notable considerations, on the down side, hot-reloading is not perfect and results in some friction. Overall, there are many wins as .NET Blazor has a variety of configurations options from server, streaming, client and even auto rendering options. This allows for considerable flexibility in web browser deployment. This flexibility combined with component re-use across MAUI (IOS/Android/Windows apps) feels like you are getting a lot for free.

If, however, your enterprise has made significant investments in Javascript development or are heavily dependent on 3rd party Javascript components, be aware that there is also friction in managing the Javascript interop with CSharp.

In conclusion, despite the friction and commitment to .NET ecosystem, Blazor development has significant potential for reducing development costs, increasing component re-use, and is quite certainly a strategic choice for enterprises who are already committed to .NET ecosystem. Additionally, with the release of .NET 8, Blazor has reached a maturity that is worthy of consideration for conservative Enterprises who prefer a more proven technology stack.

Skills Footprint:

Category Technical Specifics
general Web Development * Mobile Development * Desktop Development
standards HTML * CSS * JSON * CSharp * Javascript * Typescript
tools Visual Studio * VSCode * GIT
concepts IOS Apps * Android Apps * Windows Apps * Single Page Application * Responsive Design
packages NET * MAUI * ASP NET * Blazor * Angular