So what is Blazor?

Blazor is a fairly new ASP.Net core Web app framework, released under Microsoft in 2018. It's built in a way that let's developers use C# to specify how they want the app to work, while using HTML to layout what they expect for the user's page. You might hear that and think that having to work with both simultaneously might slow you down, but the integration between the two is surprisingly smooth. Blazor is built with WASM as the central technology. It includes both the server and user side aspects of a project and lets the developer work on either or both freely.

The strengths of Blazor may be unclear until you start working with it, but chief among them in my opinion is the accelerated rate of development due to the methods of abstraction. Being able to break apart HTML into Razor pages has been an incredible change to how I work and think about structuring my web apps.

But Jeffrey from backend said that Blazor is slow

Blazor is fast, but it's meant for complex apps, not simple ones. It's not meant to be a simple framework for a one page Halloween countdown, it's meant to be a framework for applications that need both server side and the client to work together to do something. Whether that's a blog with commenting, a forum, or a project management suite. If you're building something to solve a complex problem, use a complex solution. Blazor is incredibly fast for more complex workloads. Being able to give the user a server rendered page that loads with content as it gets responses from other processes let's you build an experience that feels better. Time to first render matters, and Blazor's caching means going from one page to the next feels great. 

Moving quickly for development

When I've worked on previous projects I've found that development speed varies a lot--how much you abstract and how you use that abstraction changes everything. Very recently I was working on a project in Rust, a language that is known for slow development time but fast, consistent execution. It was a fairly simple problem, so I was able to make sure that my structures for handling data made sense and worked well. Because I could make sure my data abstractions were good, I was able to move incredibly quickly and still, to this day, have code that is fast and easy to fix or change. 


This blog that you are reading right now is written in Blazor and was my first major project in Blazor. It has been incredibly surprising to me how easy it is to abstract things in a way that makes sense: C# is a perfectly cromulent language, and Blazor, as a framework, abstracts out enough of the language to make things easy to do. I'm not having to manually code in every interaction with a database, but I can use a simple qualifier to make sure that the code is being managed for me when I have to touch the database. That's just nice. It's certainly not unique to Blazor, or C# but having nice levels of abstraction are important and being able to expand upon them as needed in an easy, consistent way is fantastic. Easily my favorite and the central idea of Blazor is the razor component.

A portmanteau of Browser and Razor

Razor components are central to what you should be thinking of when building a Blazor app. They are the way that you specify how your app should look and behave. Building out Razor components lets you focus on the user experience and break it out into parts that are easy to manage and confined to a reasonable scope. This, out of everything else Blazor has to offer, is why I will come back to it in the future when it makes sense. Look at this page for example: the page is defined in a razor component that has a path tied to it, and a few other files configure the default behavior for a page. The Navbar, the footer, the comments, and the comment editor/creator are all separate components. This means that if I want to change any of these things separately, I can. Any other page using them get's changed in the same way. This makes UI changes a pleasure to do, and means if I change my base models, then I can make sure that I'm not having to fix every single page that displays anything to do with them. I only need to fix the components I've built that look at them.

Is Blazor the right choice?

I don't know, I think asking that question is so dependent on the problem you're trying to solve, and the team you have to work with. The best framework for the job is, in my opinion, whichever one gets it done well. Blazor feels nice to use, but there are other options out there. There is no silver bullet in tech. If you want help figuring out what the silver bullet for your project is, feel free to reach out and let's see how I can help.