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.
In my limited experience, Blazor significantly simplifies front-end development, particularly in larger and more intricate projects. This is partly due to the maturity of .NET tooling and ecosystem, which makes it easy to manage projects at different scales of complexity.
I’m not sure what you’re referring to. Blazor, along with Razor pages, was developed to simplify front-end development in dotnet. It’s essentially the React of the C# world, enabling the embedding of both C# and HTML into Razor pages, both on the client and server sides.
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).
Blazor is not robust. It is not ready for production websites.
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.
I’ve recently learnt blazor as a non-dotnet person. I definitely think it comes across as complex at first glance. The learning is pretty front loaded (especially with efcore too) but it’s not too bad once you dive in.
In particular, I am a big fan of the Maui blazor hybrid stuff. Worth a look if you fancy making a desktop app.
Yes, it can, and by default be through SignalR. The problem is both SignalR has its own limitations as well as web-sockets in general.
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)
That version of SignalR you are referring to is from .NET framework and really bolted on. That version of the framework had async/await in ASP.NET also bolted on, and the threads itself use a synchronisation context and locks.
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.