I have the same question, will Blazor United SSR still require a persistent SignalR connection? That's kind of a dealbreaker.

In Steve Sanderson's video showing off the prototype (https://www.youtube.com/watch?v=48G_CEGXZZM) he mentions around the 2min 15s mark that SSR has no websockets/SignalR or even JS required. From what I could gather, websockets will kick in when an interactive blazor component needs it. And there will be the option start downloading the WASM/DLLs in the background. When WASM is ready your app will switch from websockets to WASM. Hopefully that switch will be 'live', but in the demo it looked like a page refresh was required

It looks like the first connection will use SignalR and download the WebAssembly in the background. All connections after that will use the cached WebAssembly.

I’m 50% sure Blazor United is a soccer team

Yeah. I applaud Microsoft for their balls in launching this in its initial incarnation as part of an LTS release!

Two main things have kept me away from Blazor:

* Unclear state management story in Blazor WASM. There is a flux lib for Blazor but.. Ugh, I'm spoiled by MobX. Another project, Cortex.Net, inspired by MobX and uses Fody to make seamless fine-grain change subscriptions looked promising but the project did not gain traction :(

* Unclear runtime extensibility: How can I "plug-in" Blazor components that were not present at build time? That's a ASP.NET challenge in general TBH.

I REALLY want to want to use it though. That sweet, sweet isomorphism.

- State management: not necessarily in my opinion. This is not React. Don't use tools you don't need, don't apply principles of completely different libraries. Work with cascading parameter and contexts instead.

- Runtime extensibility: you can do whatever you want in C# so you do you. In addition there is also DynamicComponent now, which is what I believe you are looking for.