When I think about Microsoft web development, ASP.NET comes to mind. Back in the early 2010s it seemed a large chunk of web pages had “.aspx” in their URL. This is no longer the case, with decreasing numbers of active websites using it. To compete in a world flush with JavaScript web frameworks, Microsoft has focused on ASP.NET Core and derivative technologies like Blazor. But is Blazor really worth considering?
Different variants of Blazor
Currently, there are two “flavors” of Blazor: Server and WASM. Dotnet 8 is supposedly rolling out Blazor United, enabling Blazor projects to use both, but as of the time of this article Blazor United is still in development.
Blazor Server
If you want to run Blazor on the backend, then Blazor Server is for you. No one needs to download anything related to Dotnet, but every action the user performs will have to go to the server and back via SignalR. This can boost security, but if someone’s internet connection even has a little lag or if they lose connection for a second (say, on a metro), they will be disconnected entirely from the website. Even just reopening the tab on your cell phone can cause the site to rerender.
Blazor Web Assembly (WASM)
If you want Blazor purely in the frontend, Blazor WASM is for you. However, everyone who goes to your website will need to download a Dotnet runtime for your C# to execute on. This can hurt performance, but is necessary.
Blazor Pros
- Ability to write C# inline with your content. Being able to create Razor components which encapsulate HTML, C#, and CSS is a big plus.
- Ability to use NuGet packages. Like all C# website solutions, you are able to use C# packages. This is useful if your existing codebase relies on NuGet packages that you’d also like to use on your website.
- Out of the box containerization. Visual Studio provides an option to generate a Dockerfile for you to keep your site in a container. This provides a low barrier of entry into the world of Docker containers.
- Low barrier of entry to C# developers. Blazor promises to make web development easy for C# developers with Blazor and it delivers - at least at the start.
- Dependency Injection. ASP.Net Core’s Dependency Injection system makes it easy to develop websites modularly and offloads dependency responsibilities to the depedency injection service. It’s trivial to make an object a global service, scoped (where each Blazor circuit has its own copy), or transient (where the object is reconstructed each time it is needed)
Blazor Cons
As a developer who has used Blazor Server for a year, I have seen some cons using the framework:
- Lack of authentication support with prerendering. Blazor Server currently has no mechanism to manage authentication with prerendering. If you don’t use prerendering, your website will be invisible to search engines. Needless to say, that is pretty bad. Your other option is to manage authentication state yourself after page load, which results in jankiness. You are forced into a bad position here. Plus, the fix keeps getting backlogged. First to Dotnet 8, now to Dotnet 9. The Blazor team’s interim solution is to “disable prerendering for any pages that require authentication.”
- You have to pay for SignalR for Blazor Server. This is not advertised, and I only found this out after making finishing my Blazor site. To make your Blazor Server site scale you also have the overhead of scaling SignalR, which on Azure is not trivial and also expensive.
- Lack of support for other Microsoft tools. One of the sole reasons I chose Blazor was to leverage Microsoft tools, such as Azure Application Insights. However, Blazor Server doesn’t even support serverside Azure Application Insights out of the box, which is a major oversight. If I can’t even use Microsoft tools with a Microsoft web framework, what is the point? Ivan Josipovic has a solution, which I suggest anyone who needs Application Insights for Blazor checks out.
- Occasional compiler issues. When building the blazor website, my website suddenly stopped compiling. I spent two days looking into it only to find out that someone had broken inheritance in the Roslyn compiler. Despite the issue being discovered, it took over a month for the fix to roll out. In fact, they attempted to roll out a fix only for it to “not be included in the new release.”
- No CSS Preprocessor support. If you want to style your components in an idiomatic way, you have to create a “.razor.css” file. This file will be associated with your “.razor” component and will style only that component. However, if you want to use less or some other CSS preprocessor, you are pretty much out of luck. Frameworks like Svelte dont have this problem - you can write inline Less, Sass, or plain CSS with no problems. Of course, you can use a CSS preprocessor extension and start adding global stylesheets, but by doing so you are not using the scoped styling which is one of the reasons of using a framework in the first place.
Final Verdict
When I first heard about Blazor, I was interested in the technology. I was delighted by the initial progress, and the ability to utilize existing C# code. However, When putting Blazor into production scenarios, it quickly becomes a nightmare. Authentication issues preventing seamless UI experience that are blocked by prerendering, which I can’t touch or else SEO goes out the window. It’s especially frustrating for a compiler to just break and not be fixed for a month. I did have to specify the Blazor version my blazor website containers were using to get around the problem. There is a reason most people recommend Blazor for “line of business apps.” I would look to technologies with higher market shares and solutions to these common problems.