Always wanted to try our Blazor, but there are weird barriers (as a layman) to understanding the client-side lifecycle. Maybe just opaque abstractions that don't seem necessary at first glance.
Its most impressive feature, however, is LiveView, which is akin to server-side rendering. It’s more sophisticated than that. It does a diff on the state changes and only the diffed DOM node states are transmitted over the network, resulting in lightning-fast performance. In other words, if a value changes from <p>5</p> to <p>10</p>, only the 10 gets sent from the server (along with sufficient information to locate the correct location of the replacement).
Teams using Blazor are often not equipped to understand the stack and the intricacies of how it actually works under the hood, and therefore do not monitor for issues. And worse, when they become aware of these issues, they can do nothing to fix them (well, you technically can, most Blazor teams are not those teams).
>It’s essentially the React of the C# world,
No it is not even close to similar.
If you are using Blazor on a website today I bet you a very, very large amount of money your users are consistently running into issues they cannot recover from.
I know how Blazor works. A lot more than I care to.
If you are actively using Blazor today that's a huge fuck you to both your end-users and anyone being forced to interact with the application.
In particular, I am a big fan of the Maui blazor hybrid stuff. Worth a look if you fancy making a desktop app.
Things will work fine in QA, but it's not a robust framework. So when things break, they break hard, leaving your end-users in the ditch.
Something like Phoenix LiveView is a much better option.
I have never seen a SignalR (and recently Blazor) implementation without significant and characteristic issues the moment you actually star to observe end-user errors/issue/anatomies. Either through automated reporting or user feedback. And this is because SignalR is built on .NET and .NET has many different threading issues when you need those thread to be stable and robust (not talking about transit B2B apps)
It always happens. Without exception.
You do not have to take my word for it, look at the active, open, and historical issues here: https://github.com/SignalR/SignalR/issues
The issues are plainly fundamental.
It's absurd. And it only survives because it's Microsoft.
This is mostly no longer the case in modern .NET. SignalR is a core part of the framework and completely rewritten.
In our case, Blazor Server has been very stable for us, also for multiple users.