One year with Blazor

After having stumbled through the Javascript swamp for almost 10 years, we were ecstatic at the promise of creating rich web applications in .NET exclusively. Our experience was a positive one and we have since cemented Blazor into our development toolkit. We are at a point where we are comfortable developing any new web applications in Blazor only. With the advent of .NET 6 just beyond the horizon, we will be able to have a unified web and desktop experience by using the same code base.

We will talk about some of the challenges we faced wih Blazor, as well as all the positive things that have come out of ditching Javascript.


Challenges were few initially and once we overcame them, they did not come back again. It is true that Blazor has a non-trivial learning curve. While setting up a simple application using the provided template is simple enough, but when it comes to the more advanced topics, it takes a little bit of trial and error. We talk about some of the challenges we overcame in some of our other blog posts, so we won't rehash them here. Suffice it to say that Blazor's runtime model has a number of gotchas that developers need to be aware of if they are writing more complex applications.

Single Codebase

One of our favorite things about Blazor was the fact that we didn't need to maintain essentially two codebases. While yes, they are part of the same solution, when you write a traditional Asp.Net Core + Angular/Vue/React/Whatever application, you have your backend code and then you have your frontend code. Typically you have different engineers, sometimes even different teams who work on one or the other. This introduces various maintainability headaches to say the least. It also introduces extra cost, because more engineers are needed to work on a given application. Furthermore, if your dedicated frontend engineer leaves the company and he was the only one who knew Angular (yes, we have seen this happen), that will be very painful.

With Blazor you have one codebase. And what's even better, you can put your business logic directly into your Blazor pages and components if it makes sense to do so. You are not forced to create dedicated api endpoints, just because Javascript needs a way to get the data. If you are running Blazor server, it already has the data at its fingertips. Just inject the database context, and you're cooking with gas!

But the best thing is, all your code is now in C# and one engineer can work on the entire application without having to do any context switching.

No Build Tools

If you have worked with modern Javascript frameworks, you are probably familiar with the never ending tools available to you. Npm, Gulp, Grunt, Yarn, Gradle, Parcel, RequireJs, Brunch, Browserify, Webpack, and so on. There are even languages built upon Javascript, like Coffeescript and Typescript that address the inadequacies of Javascript. There have been times when we were wasting resources investigating issues related to these build tools rather than just writing our code.

With Blazor you only have one thing to worry about. Does it compile? There are no extraneous tools to run or configure. You just run it like any other .Net application.


The Javascript debugging experience is not terrible if you have set it up correctly. However, it's no match against debugging a Blazor application. It goes without saying that having our business logic and UI code in the same environment and being able to debug both at the same time without interruption is far superior. This was one of the most beneficial process changes we have experienced while working with Blazor Server.


You deploy a Blazor app like any other Asp.Net Core app. With Javascript it's a lot more complicated. You still have to deploy your backend code. To deploy the frontend, you have to run one of the aforementioned tools to build and minify all your code (and probably more). Then you run another deployment just for the frontend.


Blazor comes with all the niceties of modern Javascript SPA libraries/frameworks. You get two way binding, routing, components and more. The advantage is it all happens inside the same runtime where your business code is running.

Never Going Back

After one year of working with Blazor, we have decided we are going to continue working with it for the foreseeable future. Microsoft is continually improving upon it and we are excited what .Net 6 and beyond will hold in store. Here's to a Javascript-less world! We think it's only a matter of time before Blazor picks up steam and starts chunking away at Javascript's market share.

Table of Contents

  • Refit and Controllers

    We talk about how to create apis alongside your Blazor app and how to access those apis using Refit.

  • Blazor Gotchas

    This article explores various Blazor pitfalls that you should be aware of.

  • Blazor and HttpContext

    Here we discuss how to correctly use HttpContext in a Blazor app.

  • SignInManager and Blazor

    Blazor and SignInManager don't play well together. Let's see how to get around that.

  • One Year with Blazor

    We've switched over to using Blazor exclusively a year ago. Here are our thoughts.

An error has occurred. This application may no longer respond until reloaded. Reload 🗙