IMO, server-side Blazor is a non-starter, basically just a proof-of-concept to get something up and running before the WASM version is usable, but definitely not something I would use in production.
Why not? Works fine in our tests, and a large part of .NET apps are internal apps that work great with this kind of framework.
I think the biggest issue is sending every interaction over the wire but there are ideas to separate the event handling or even split which components run server vs client-side. That would allow highly responsive inputs with no lag while the parent component can run all its logic on the server.
I mean, sure, if you have tens of internal users maybe (but then it could be argued that it could just as well be deployed as a desktop app -- I could buy the deployment method as an argument, mind you). But thousands? Call me sceptical. It just makes me think of `asp:UpdatePanel` all over again.
Are you referring to the session state and websockets connections? Both scale horizontally with minimal effort, I don't see the problem.
Asp:UpdatePanel was great for it's time, and no different than doing an XHR request now and replacing the contents of a div with the response. You can still get basically the same effect with libraries like Turbolinks which is what Github does.
I think the biggest issue is sending every interaction over the wire but there are ideas to separate the event handling or even split which components run server vs client-side. That would allow highly responsive inputs with no lag while the parent component can run all its logic on the server.