Which is kind of return to WebForms, GWT and JSF ways of working, only the implementation is a bit different than on the 2000's.
We moved into MVC approach, because of the headaches that it used to be having to debug all the generated stuff from what the browser actually supports as built-in technology.
I don't see that bright future for Blazor, other than a few .NET shops that don't want to learn native browser technology.
The debugging experience and the lack of context shift when going from thinking about how C# works to JavaScript (and all its zillion quirks!) is insanely better. I can put a breakpoint for the front-end and debug it just fine withing VS. I do wish Microsoft would finally open source their debugger, since I've heard loads of complaints about it being proprietary still.
With VS, and it still doesn't do anything when it is something broken at the browser level, CSS, HTML, JavaScript, that the VS debugger provides zero information, just like with WebForms.
I'm not sure I've run into such a state yet, are you using Blazor without any UI component libraries? I am using MUDBlazor, genuinely curious what you're running into.
I used it enough to understand how it works, compare it with my WebForms, GWT and JSF experience since their early days in 2001 onwards, and decide to stick with MVC, and browser native stack.
Additionally, our agency is polyglot, and in no way frontend teams are going to start doing Blazor instead of their favourite framework of the month.
We moved into MVC approach, because of the headaches that it used to be having to debug all the generated stuff from what the browser actually supports as built-in technology.
I don't see that bright future for Blazor, other than a few .NET shops that don't want to learn native browser technology.