What factors should you consider when choosing between Blazor, React and Angular for building a modern web app?
With an ever-expanding sea of frameworks, tools and ecosystems from which to choose, it can seem harder than ever to figure out the best option for your business when it comes to building modern web applications.
Well to start, we should probably define “best.”
This is likely to vary based on your own unique situation, but I bet for most of us it boils down to a few factors.
After all, even if one of these frameworks were technically far superior to the others, if the learning curve meant you couldn’t do anything meaningful with it for the first three months, it probably wouldn’t be your first choice!
So how do Angular, React and Blazor stack up, and what key differences should you look out for?
The first big consideration is the makeup of your team.
If you have a team with lots of C# experience, and especially if they’ve built web applications using ASP.NET MVC (or ASP.NET Core MVC), then it may be wise to capitalize on this experience.
If C# is the primary language of your enterprise, then Blazor may be the best choice. It also avoids the pitfalls of having multiple languages to maintain.
Aside from differences in the languages themselves, there’s also the development environment to consider.
It used to be that .NET developers generally used Visual Studio, and anyone building frontend apps with something like React would use a different tool.
These days tools like Visual Studio Code have successfully brought the various camps together to varying degrees.
Saying that, if your team is comfortable and familiar with one particular set of tools, it may make sense to keep them there.
It’s no small undertaking to switch from one coding environment to another. Over time we tend to get used to the tools/configurations we use all day every day: Shortcuts, extensions, themes all help to keep us on track.
It’s not an impossible mountain to climb, to switch from one tool or editor to another, but doing so is likely to slow everything down, at least in the short term.
If IDEs and text editors are an important factor when it comes to development, how you get your code to production is just as (if not more) important!
Angular, React and Blazor all have their own processes for deployment.
In general, it’s a matter of running the correct script to package up your apps before deploying them to some form of host.
React and Angular can be deployed to static web hosts like Netlify or Azure Static Web apps.
Blazor apps can also be deployed statically, but only in some cases.
If you’re using Blazor WebAssembly, your app can be deployed statically, unless you choose to host it via an ASP.NET application (at which point you would need an ASP.NET-compatible server).
Blazor Server is not deployable statically as it also depends on an ASP.NET backend.
Static hosting has many advantages, not least it’s generally cheap (often free) and very fast because there’s no dynamic processing involved. Static resources can also be served from CDNs, meaning your users are downloading your apps assets from a server geographically closer to them than your standard web server is likely to be.
If you’re deploying your sites using continuous integration/deployment you’ll also need to factor in how easy it is to configure your CI/CD server to deploy these sites.
Again, if your team has experience deploying ASP.NET sites, Blazor will be a closer fit.
Angular/React deployment depends on running scripts which use node.js (under the hood) to package everything up into a deployable asset.
Another significant factor when choosing any technology is the ecosystem in which it exists.
There are many factors here…
Is it actively maintained, is it likely to evolve and improve over time, how easy is it to get help/support?
Blazor is the newest kid on the block, so you might expect there to be some gaps in terms of the answers you can find online.
Saying that, there is an ever-growing Blazor community and people are writing about it regularly, so this is likely to be a short-term problem (if a problem at all).
In some ways, Blazor has an advantage arriving after Angular and React in that many of its fundamental underlying principles are drawn from the best parts of those frameworks.
In that sense it’s hit the ground running and the component model is logical, consistent and predictable. So once you’ve grokked the basics, it generally works as you would expect.
Angular and React have been around longer and you can generally find answers to any question you might have.
It’s worth noting there is a fundamental difference between React and Angular.
React ships with a component model and the ability to bind components to data but very little else.
This is a deliberate choice by the React team, leaving it up to other parties to provide additional concerns like routing, support for forms, etc.
Because of this, React itself is fairly straightforward to learn (due to its relatively limited scope).
Angular, on the other hand, includes routing, forms and virtually anything else you can think of.
The upside of this is you don’t have to jump off to various third-party providers to plug the gaps, but it also makes the surface area of Angular much, much bigger, meaning there’s a lot to learn.
So, depending on your team’s learning style and existing experience, they may get on better with one of these frameworks over the other (from the perspective of learning the basics and getting something up and running).
Blazor occupies a sort of middle ground here, shipping with a solid component model, plus routing and forms, and an HTTP client for making network requests.
Overall Blazor is “lighter” than Angular in this regard. It also builds on established Microsoft technologies, so if your team is familiar with ASP.NET routing and writing markup using Razor, much of Blazor’s functionality will come naturally to them.
Another key factor when adopting any framework is the level of commercial support available.
There can be much to gain from using third-party solutions, like UI controls, in your application. Building things like grids, charts, text editors, etc. always takes longer than you think, and ultimately has the potential to become a significant distraction from actually shipping the features your customers need.
In this area, all three frameworks have excellent, and ever-improving commercial support. Blazor, despite being the newest kid in town has an ecosystem with rich tools, such as Telerik UI for Blazor, already available to speed up your development.
It’s probably not worth getting into a game of predicting the future for these frameworks, but it is perhaps worth weighing up a few factors.
Microsoft is currently investing a lot of time and effort into Blazor, with the framework itself evolving rapidly and tooling improvements arriving at regular intervals.
It’s integrated into a suite of sweeping changes coming with .NET 5 and appears to now be a significant part of Microsoft’s plans for building modern web applications moving forward.
React also shows no signs of slowing. It’s the core technology that powers Facebook (where React originated), and releases arrive on a frequent basis.
Angular aims for major releases every 6 months or so. At the time of writing, the last version released was 10.0 in June 2020.
Finally, there are differences when it comes to which versions of the various frameworks are supported.
React’s support is all community based, as outlined here.
Angular has an official policy regarding which versions of the framework are supported.
All major releases are supported for 18 months, with 6 months of active support (when regular updates and patches are released), then 12 months of long-term support (only critical and security patches are released).
With .NET (and therefore Blazor), the platform is officially supported by MS just like any other Microsoft product.
Each release is either Current or LTS (Long Term Support), and this is done on an alternating basis.
LTS releases are supported for three years after release.
Current releases are supported for three months after a subsequent Current or LTS release.
All three here are solid options for building web applications.
Still, it’s important to weigh up the experience and preferences of your team, as well as bearing in mind how easy or hard it is to learn a new tool/language, when picking any of these options for your next project.
If it’s still not clear what direction you should run in, it might be worth taking the time to create a small application with each.
Keep it simple and build something small, with a couple of screens, just to see how each of the frameworks work; how to create and link components, options for routing, etc.
Clearly this is no substitute for actually building an entire application, but it will help identify potential obstacles standing in the way of adopting any of these frameworks.