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.

What’s more, until recently JavaScript was generally considered the go-to option for building “modern” web applications, but now, with Blazor, Microsoft has created a viable alternative.

Blazor, like JavaScript, runs in the browser, but your applications are written using C#. Your application and a small version of the .NET runtime are then shipped to the browser where everything runs via WebAssembly.

So now we find ourselves with established JavaScript frameworks like Angular and React, plus a new contender in Microsoft’s Blazor. Which one is best for your enterprise?

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.

• How does each framework help (or hinder) your team to build stable and scalable web applications
• How easy is it to get support/answers when you get stuck (or run into unexpected problems)
• How well does it fit in with your team’s existing knowledge/experience and your existing technology ecosystem

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?

Leverage Your Existing Skills

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.

For many C## developers, JavaScript is either a complete mystery, or at least yet another thing to learn.

Although it is possible to transfer some of your existing C## knowledge when you start writing JavaScript, they are fundamentally different languages, and the nuances of writing for JavaScript can catch you out, especially when you’re used to writing everything using C#.

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.

On the flipside, if your team is more comfortable with JavaScript, then React or Angular may be the better choice for similar reasons.

Tooling

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.

Deployment

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.

This works because they are composed of JavaScript, HTML and CSS, none of which require dynamic processing and can easily be served to the browser from virtually any web host.

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.

#angular #react #blazor #javascript #developer