Julio Sampaio Software developer, with an affinity and curiosity for everything else. 🤔💡

Blazor vs. Angular

6 min read 1919

blazor vs angular

Angular, formerly known as AngularJS until 2016, was created to allow frontend developers to interact with both frontend and backend at the same time. This was very helpful at the time, especially because the backend was usually made with other languages, like C# or Java, which means it was generally maintained by other developers too.

With the advent of SPAs, Angular became even stronger, and new frameworks arose to compete with it, like Blazor from Microsoft. Blazor is a web framework, that allows you to run C# along with HTML and CSS, creating components and generating SPAs. It was written under the .NET platform, which brings you all the power of Microsoft’s framework, both in the client and the server.

In this article, we’ll make a comparison between Angular and Blazor. We’ll analyze their community strengths, the PWA/SPA support, their async nature, and architecture.

Angular pros

Because Angular is JavaScript based, there are a lot of resources to work with. Let’s analyze some of them a bit closer.


Angular has been around for a long time, unlike Blazor. It is a production-ready framework with full support for MVC/MVVM applications and it is being used by many large companies. Blazor, on the other hand, is continuously being changed and has not yet achieved enough maturity to dispute with Angular, despite being very promising.

When it comes to tooling, Angular is ahead. Angular has VS Code support for development that Blazor only implemented very recently.

Regarding the libraries, Angular Material, for example, is one of the most famous, especially because it embraced Google’s Material Design, a design language very common in Google products. Apart from that, there are other major design libraries you can easily set up, like Bootstrap, through the NG Bootstrap library, or PrimeNG, for example.

Blazor has been working on an equivalent version of its own Material Design library, but it’ll take time to achieve such maturity levels.

Angular also offers several options when it comes to component libraries. In this link, you can find the list of the official Angular supported tooling, including IDEs, UI components, and data libraries, among others.


Angular is extremely popular. At the time of this writing, it’s GitHub repository counts 63.7k stars and 17.2k forks, it is definitely an important and beloved framework in the frontend community.

We made a custom demo for .
No really. Click here to check it out.

It’s hard to analyze Blazor’s popularity, the project was moved to the ASP.NET Core repo, since it has officially become part of the ASP.NET project. Before the repo was moved, Blazor had 9.2k stars and 700 forks. We’re not going to consider the ASP.NET Core stats, since they involve a lot of other factors other than Blazor itself.

Another good comparison is Stack Overflow. Until now, Angular alone has accumulated a total of 224.3k questions while Blazor only has 2.9k questions.

comparison of questions in stack overflow for Angular 224.3k questions and Blazor 2.9k questions
The number of questions of Angular and Blazor at stackoverflow.com

When you compare both techs in Google Trends, the gap becomes even more clear:

Google trends page with Blazor and Angular in graph

With such a community strength, and by existing for way longer, Angular was able to grow (in terms of number and quality) a more extensive community than Blazor did. There’s more content, courses, books, blogs, and materials about Angular than you’ll find for Blazor.

PWA support

Google is a big fan of Progressive Web Apps (PWAs), and therefore so is Angular. Its usage can be added to your Angular apps by simply running:

ng add @angular/pwa

You can guess that for other Google projects, like the famous Workbox, for example.

For a long time, Blazor was categorized as a framework not capable of doing PWA. They’ve recently announced that they do support PWA, however, as with many things with Blazor, that’s a work in progress. Besides being stable, some developers complain about the initial download app size being too large, whereas small bundle sizes are considered crucial for SPAs.

However, the community remains optimistic about the PWA support. It’s not ideal yet, but it’s constantly evolving.

Scoped styles

Angular, as many other web frameworks and libraries, allows the usage of Scoped styles, in which you can apply a CSS style specifically for a related component, for example:

  selector: 'app-root',
  template: `
    <h1>Title H1</h1>
    <app-test-main [title]="title"></app-test-main>
  styles: ['h1 { font-weight: normal; color: red; text-transform: uppercase; }']
export class AppComponent {

This will result in a view like this:Red header saying Title 1

That’s a controversial feature that’s not supported by many browser’s versions and is still being discussed.

But it’s certain that the functionality is interesting. Blazor lacks it, although some people are already trying alternatives out. It’s up to you to decide if Scoped Styles are important enough for your projects.

Wrapping up

Angular has proved its value throughout time. Among other items, you should use it because:

  • It is complete, offering smooth support for MVC/MVVM applications, as well as SPA and PWA
  • It is mature, with a handful of IDEs that support it
  • It is stable and production-ready, with a long road of successful projects made with it
  • It is popular and backed by a huge community of open source developers, under the blessing of Google
  • It supports Scoped Styles

Blazor pros

Blazor is good for some specific reasons that we’re going to explore in more detail now. One of them is the fact that it is C# based, which means that if you like object-oriented languages (or any of the C# features), you’d feel at home. C# is strongly typed, and has tons of auxiliary libraries to enhance your coding.

Server-side rendering

This feature is well-known by many frontend devs, especially with the Next.js framework. But Blazor prefers to call it “prerendering”. The feature consists of compiling all the app’s components and elements on the server side and, then, generating static HTML/assets to send to the client.

The main benefit is the overall performance. Prerendered pages are way faster than the ordinary ones, helping also to perform better at the SEO results. There is, however, a whole concept behind its use which I’d very much recommend you study prior to adopting it.

WebSocket connections

Blazor makes use of a WebSocket connection to flow data back and forth. Because of that, its initial page size when downloaded is reportedly smaller than in Angular. Perhaps, the difference is due to the verbosity and boilerplate codes Angular brings within its downloaded bundles.

Other than that, when in a HTTP/2 server connection, tests via signalR (an ASP.NET library that adds real-time web functionality to your applications) have proved that the latency is very low as well as the message framing not having to establish connections.

In other words, the ability of an application to send messages from a server to the clients in real-time is a great way to test if the language ー alongside the protocol being used ー is really fast. In your client, then, you can measure the timing between the requests and responses and check how fast it was.

The same WebSocket could also be used to send data via push to your Blazor components in a very fast manner.

Build/coding time

Blazor is very fast in terms of build and debugging. Because it takes advantage of Visual Studio and the whole experience accumulated among its tools and plugins, the development and debugging can be really fast (depending, of course, on your level of experience and familiarity with them).

Blazor also brings the noted live reloading feature during the development that you can set up in no time:

// Add NuGet package:
dotnet add package RazorComponentsPreview

// Add to the StartUp class:

This feature depends on the compilation and build time. The performance comparison of the same functionality between Angular and Blazor brings the latter to up to 20 times faster, including builds running in CI/CD pipelines. That’s a lot.

In terms of coding, Angular is known for its boilerplates. With Blazor, you’re already in the back-end, which means that you can write methods on services that can be directly called from the upper layers, rather than going through a whole API structure call as you’d have to do in Angular.

Async nature

While Angular makes use of the built-in async nature inherited from JavaScript, it also supports the powerful RxJS to handle the async operations. C# has evolved itself to support it out of the box in a simple and clean way. Sometimes, you can even feel that some implementations are very similar between both techs.

For example, imagine that two client apps made with Angular and Blazor, respectively, consume from the same API endpoint.

Due to their async natures, we would have the following code for both calls:

// Angular
async getUserData() {
   return await this.httpClient.get<User>("api/users").toPromise();

// Blazor
public async Task GetUserData()
   return await Http.GetFromJsonAsync<User[]>("api/users");

Can you spot the similarities? The async/await operations allow us to wait for a single asynchronous operation to complete. This same operation can only complete one time, and will always have a single result. And, yes, they equally apply to Blazor and Angular.

Wrapping up

While Blazor is still giving its first steps, it has proved that it is willing to keep improving and hearing the community. Some reasons why you should use Blazor include:

  • Its .NET-based nature, which brings the object-oriented power characteristic of C# language
  • Its server-side rendering (the prerendering) feature, which can highly scale the app’s performance
  • Its fast build time along with live reloading capabilities
  • The ability to work asynchronously in no time and small efforts

Comparison table

Here’s a comparison table summarizing the post, so you can address the differences in an easier way:

Angular Blazor
JavaScript based C# based
Fully support SPA and PWA Supports both, but PWA is a work in progress
> 63k stars on GitHub > 9k stars on GitHub
Production-ready Can be used in production, but it is still receiving changes
Mature tooling and design library The common tools (like IDEs) are working to add support

Design library in progress

                                                               Open source
                                                           Supports async features
Supports scoped styles No support yet
Download size: ~111K Download size: ~2MB-2.4MB
CI/CD time: 10-20 times slower CI/CD: 10-20 times faster


It’s good to remember that both frameworks are robust and try to solve common problems the community faces. Both are also open source.

When compared to Blazor, Angular stands out in some important ways. For example, if you’re a frontend developer, and have never been in touch with backend languages or .NET, going to Blazor can be tricky, since you’d have to learn C#, .NET, and Razor.

If you’re hiring people to work in your frontend projects, chances are that you’ll have some trouble finding good Blazor developers, against a large number of Angular devs available out there.

Besides those differences, there are some great similarities between both of them. Their routing systems are very similar, although Angular’s is a bit more complex and requires more boilerplate code to work. They both have great libs to deal with HTTP calls (perhaps a good inheritance from their creators), and great template systems (some parts of them very similar).

What about you? How was your experience using the two of them?

Experience your Angular apps exactly how a user does

Debugging Angular applications can be difficult, especially when users experience issues that are difficult to reproduce. If you’re interested in monitoring and tracking Angular state and actions for all of your users in production, try LogRocket. https://logrocket.com/signup/

LogRocket is like a DVR for web apps, recording literally everything that happens on your site including network requests, JavaScript errors, and much more. Instead of guessing why problems happen, you can aggregate and report on what state your application was in when an issue occurred.

The LogRocket NgRx plugin logs Angular state and actions to the LogRocket console, giving you context around what led to an error, and what state the application was in when an issue occurred.

Modernize how you debug your Angular apps - .

Julio Sampaio Software developer, with an affinity and curiosity for everything else. 🤔💡

13 Replies to “Blazor vs. Angular”

  1. You appear to have mixed and matches elements of client side and server side Blazor.

    I had client side Blazor apps running as fully disconnected PWAs 8 months ago. And while the client side Blazor apps do have a ~1.5 Meg download, that is fully cached, server side implementations do not.

    Server side implementations of Blazor sites with heavy real time interactions are also way more efficient as you’re not dealing with a dozen Ajax service calls and managing state client side. All those interactions are on the server, so no communication issues.

    Blazor is still young, but we’ve already been converting our angular and react sites over to it. We’re even looking at forgoing an investment in an externally built mobile app in favor of a Blazor client side PWA. Getting out of the hell that is JavaScript is worth it alone, adding in the increased dev speed, and that any of our C# developers can jump right into web and mobile development is huge.

  2. I believe you have some items in the wrong columns where you list differences between the 2 frameworks. Right before your conclusion.

  3. I couldn’t agree more. There seems to be a mix up with Blazor Server and Blazor Webassembly. Which is less mature still, but I love it. Just to escape the madness of JS.
    Also he says that Angular is Async by default. This is just not true of Angular, and the simple Typescript example he gave may well work. But as soon as it gets even vaguely complex you are into understanding a while new world of ‘observables’ et al, and they dont mix well.
    C# just works.
    Also, as you, I built my Wasm app as a PWA and that just worked too.
    Most interested though what you said about canning the App. We are at a crossroads right now with our existing tech, using Xamarin.
    Very interested in the Blazor on Xamarin Forms experimental tech coming along.

  4. In your comparison table you show Angular as production ready with caveats of undergoing updates, but Blazor is simply described as production ready. I think this is misleading. You could apply both definitions to both products, but I could also argue that Angular has been ‘more’ production ready for longer, having been implemented in countless hi-profile projects for a decade. Further, while you report PWA as a work in progress for Blazor, for Angular, as you write, PWA capability is nearly as simple as a single CLI line entry in an Angular project.

    Full disclosure: I’m a .net(Bootstrap) full stack dev by day, and Angular(.Material) dev by nights/weekends. I’m not very familiar with Blazor, other than spinning up a few practice apps during tutorials, but have more experience with the traditional asp.net product. Still, I like both platforms, and SPAs and PWAs in general. For IDEs, I prefer to use VSCode for Ng CLI dev, and visual studio for asp.net dev.

  5. Blazor isn’t going to replace Xamarin, I don’t think. You’re still limited to the DOM and the performance capabilities it has. So if you’re looking to push pixels and get OS level interactions, Xamarin is still (IMO) the way to go.

    But if you’re doing some simple rendering and basic I/O, say like getting your insurance card or a shopping assistant for a big box store, Blazor lets you do so, without having to bring in a new technology, no significant learning curve, no new environments, no worrying about dozens of hardware setups and OS versions, and best of all… NO JAVASCRIPT! 😀

  6. Hey guys, I’m super sorry for the wrong items on the comparison table. I’ve mistakenly swapped some of them and now it’s fixed.

    Regarding the comments, thanks for enriching the discussion here. My goal is to collect your thoughts and adapt the post if something is not accurate enough or wrong.

    Thank you! 🙂

  7. Perhaps a more apt comparison of popularity of the two frameworks using stackoverflow would not be to compare all time questions of each, but instead to search for all questions in 2020. “[angular] created:2020” (90k) vs “[blazor] created:2020” (5k). It should also be noted that many blazor related questions may fall under the [dotnet] tag, since blazor has been merged into the .NET codebase.

  8. Not even remotely true. We write our angular applications 100% RFP in Rxjs and it works perfectly. We backend it with dotnet core webapis using rest and protobuf, and a micronaut graphql layer. We also deploy high performance code to the client using Rust compiled to wasm in 1/30th of the space the runtime for Blazor uses.

    I’ve also been using Rx since it was a new experiment by Meijer on dotnet, dotnet since beta, and win32 api on C++ before that, so I’m not stranger to any of these paradigms.

  9. With Blazor 5, scoped styles are supported. Simply add a css file called MyComponent.razor.css on the same location as your component and you are ready to go.

Leave a Reply