Disclaimer: When writing this post, I was working on a full stack application with a Blazor frontend for six months. In this post I will write about four reasons why I dislike working with Blazor.
Reason 1: Finding the CSS settings for a HTML element
Let's imagine during development I want to check the CSS settings for a HTML element via the browser's console. In our case it's a simple button and the browser is the latest Chrome version (109.0.5414.120). The website preview is provided by the Visual Studio debugger.
The usual way to find out the currently applied CSS settings for the button, is to right click on it and then hit "inspect". Normally this pops up the developer console and in the Elements tab it navigates directly to the button element, also displaying its CSS settings in the Styles tab. Very convenient, but not with Blazor. Because in Blazor right clicking on an element and clicking "inspect" will only pop up the developer console. Just the same way as it would as if you hit the F12 key. To finally navigate to the button in the Elements tab and view its CSS settings in the Styles tab, you need to repeat the action of right clicking on the button and clicking on "inspect". And this leads us to...
Reason 2: <!--!--> (Solution: disable HTML comments in the dev tools)
These HTML comments are flooding the developer's console Elements tab, where the HTML hierarchy is shown. They make it a nightmare to learn about the relationship of different HTML elements. Usually I expect to see something like this:
<section> <div> <form> <label></label> <input /> <button></button> </form> </div> </section>
But not with Blazor. In Blazor it will more look like this:
<section> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <div> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <form> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <label></label> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <input /> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <button></button> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> </form> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> </div> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> <!--!---> </section>
This of course makes it very annoying to research the relationship of HTML elements. And that's all I can say about it.
Reason 3: Build time
As mentioned in the title, I come from a React background. I'm used to see changes done in the editor almost immediately in the browser preview. But not with Blazor. It has some kind of hot reload, where the browsers content is updated without a full debugger reload, but even this will take a few seconds. And more than often, the whole application needs to be rebuild to get all applied changes through to the browsers preview. In our application it takes around 15 seconds to build the page via the debugger. Multiply this 15 seconds by the many times changes are applied in a normal frontend working day and this will be a significant time factor. Also I have noticed that my brain sometimes looses focus during the rebuild time and I have to gain it again, once the page is loaded. To be fair, at least I recently noticed an upgrade for CSS settings, which are now displayed even quicker than what I'm used in React applications.
Reason 4: Jumping into the Sources tab and pausing the page build on browser refresh
When working on the frontend of the application and wanting to change the appearance of, it is common to apply HTML and CSS changes in the IDE and then refresh the browser, to see the changes there. Also it is very common to have the developer console open at the same time. But not with Blazor. Because Blazor will jump into the Sources tab and pause the page build many times until it's finally done. To speed up this process, the only way I found was to close the console first and refresh the page then. Once it is loaded, the console needs to be reopened and the part where I was working on needs to be found again. I could not find any long term solution to fix this issue. Because Visual Studio will fire up a separate Chrome window when starting the debugger and applied changes to the developer settings are not persistent there.
Reason 5: Not a reason to hate Blazor, but nice to know: Blazor loves caching
In my experience Blazor is caching everything it can, more than other technologies. That's why you often need to reload the page without the cache to see changes in HTML and CSS. One way to do it is to hit Ctrl + F5. Or you could open the Network tab in the developer console and check the "Disable cache" option.