Blazor United looks ambitious but sounds great! The goal feels similar to that of Remix.run and a few other frameworks that are blending SPA/SSR.

I do wonder about the scalability of the Blazor Server mode which requires live and "sticky" SignalR connections.

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.

Microsoft has been on a roll with .NET releases, it's been a 30 minute or so upgrade process for us to go from 5 -> 6 -> 7. Looking forward to the new Blazor model!

I wonder if it'll be possible ever to do Native AOT if you rely on Newtonsoft (which is reflection heavy, last I heard). Yes, yes, I know, use System.Text.Json, but I already have all this code relying on Newtonsoft-y things :(

It's worth the work heading to System.Text.Json - even if only to make staying up with .NET easier for yourself.

It had a bit of a rough start but it seems far more interoperable on weird edge cases than Newtonsoft now, so all the "Newtonsoft-y" things you're doing might evaporate.

I've had the opposite experience. System.Text.Json adheres extremely close to the RFC and barely handles any edge cases. Newtonsoft will happily serialize invalid json. Not that you want that but if you have a legacy system it's not worth migrating. James Newton-King is a Microsoft employee btw.

Isn't Text.json also faster at this point because it uses all the new span goodness and the like?

I'm pretty sure it's been faster for as long as it's existed.

Turns out it's easy to be fast if you don't have any features.

Even better: it has an optional source generator now! So, at compile time, C# can be generated. This can be at two levels: (1) just generate metadata so runtime reflection is not needed, or (2) also generate code that does the serialisation or deserialization itself.

Pretty cool!

> but I already have all this code relying on Newtonsoft-y things :(

Welcome to the dungeon... Our jailer is polymorphic deserialization. We've got many gigabytes of Newtonsoft JSON in prod with that $type property throughout.

Any place I can use System.Text.Json I will, but there are a few legacy usages that absolutely won't work.

At this point, I'd like to rescind any expectation/desire for Microsoft to support polymorphic deserialization in their JSON library... It was a super powerful trick to get us to the next step, but it eventually turned into a nightmare for codebase maintenance.

Until we have this monster refactored, we won't be able to move most of our types into different namespaces or assemblies.

I have been using Blazor Server for a project at work.....Honestly, it is so much better than using .Net MVC/Core with js sprinkled in.

I developed stuff in java for android, swift for ios, and now mostly work in c#, SQL, .Net MVC/Core, blazor. Microsoft stack feels pretty good to me. Getting a start up job is a bit difficult, I came across two startups using microsoft stack and only one paid SV money.

C#/.Net does have a pretty stable job market but pay is a bit lower.

The trick is to start the company yourself. :) We're 3 years in and full .NET stack.

Is your project an internal app or public?

I'm cautiously optimistic about Blazor Server but I'm not sure I like the sticky SignalR requirement. The expectation seems to be that the backend server will keep around a lot of state (cough viewstate?) in memory associated to that session. It's a very convenient dev experience for sure, but it seems difficult to scale beyond internal business apps.

This is why they recommend using the Azure SignalR Service, I guess :)

Indeed. That's that the only way I'd consider it. Luckily, they are generous with the free messages. Last I looked it was about $161 per day to scale to 100k concurrent users. But that's just SignalR. We'll also need much beefier AppServices with lots more memory than what we use now.

Not quite sure how it works beyond that when you need multiple service instances connected with a backplane. The new premium tier I just saw sounds convenient though.

https://azure.microsoft.com/en-us/pricing/details/signalr-se...

https://youtu.be/OsdBpMumf_c?t=635

It is an internal app, otherwise I would go for web-assembly with an API.

dev on .net is something I can understand ... but deploying and running windows servers in prod sounds like a hellish nightmare

The full .NET stack runs on Linux now. It’s even in RHEL’s repos. Heck you can even run MS SQL Server on Linux now if that’s your thing.

It is in Ubuntu and the AUR ( Arch ) as well.

In pragmatic terms, .NET is as native as anything else in Linux at this point.

You can even build it from source: https://github.com/dotnet/dotnet

In fact, the VMR ( linked above ) ONLY works on Linux at the moment with Windows and Mac support planned. So, .NET is Linux-first in some ways.

MAUI is not Linux first of course. The rest of it is becoming more and more Linux and container focussed though it seems.

You can run it all on linux and containers or whatever you want these days.

Where I work, we all use MacBooks and deploy our services on Linux boxes. .NET has been cross-platform for years now.

What kind of setup do you have to avoid users noticing the drop of their websocket connection due to a deployment? Blazor Server development experience is very good, but even for an intranet application, it can have a poor user experience by default due to the requirement of a persistent connection.

It is yet to be launched but it will be used by a small number of users in a intranet.

If there are issues I will just convert to webassembly.

We've deployed multiple applications without issue over extranet. We release our apps usually outside office hours so a dropped connection or two isn't an issue. Just make it clear when there will be maintenance.

It's easy to start with, as I did, but do yourself a favor and move to Blazor Webassembly. Blazor Server handles UI events in a centralized way, and network lag really destroys the application. It might be ok on a fast and reliable intranet, but you really don't want to use it on the general internet.

Standard Blazor Webassembly project setup creates a server side project and a client side one. C# code on the client side is compiled to Webassembly. You then set up your server side functions called from the client side with usual C# .NET REST functions. This is less convenient than the Blazor Server model, but it captures the actual complexity of internet networking. It's also fast. You can put a lot of (hopefully non-confidential) processing onto the client side, running locally in the user's browser using a huge array of .NET library functions including from NuGet. It really is the way to go.

The load times and lighthouse score for the MUD Blazor site has put me off of Blazor entirely for anything public facing:

https://mudblazor.com/

Blazor Server works well for low-latency Intranet Apps, it's stateful SignalR rendering circuit isn't suitable for laggy Internet Apps where deployments and long running Tabs results in users seeing frequent YSOD's.

Which can be avoided with Blazor WASM that has different trade-offs with poor start times & SEO. Hopefully something that can be resolved with their upcoming Blazor United solution, which I'm assuming means no longer being able to host Blazor WASM's static assets from a CDN.

This is what we use it for. All of our internal admin/devops dashboards are built using blazor server. Employees on the east coast have the best experience, but no one in Texas seems to complain (server is in Virginia). We don't have any employees west of Austin, so latency works out fairly well for us.

Same here. Blazor Server is so awesome. It really allowed us to focus back on the business problems rather than getting some Stockholm syndrome about a library or framework that is actually just in the way and you have to take into account all the time.

It also allows to add real-time functionality in a breeze. Even business applications can profit from that, but you often just skip that because it is not worth the effort.

I had a conversation on HN w/ a MS engineer last week about the System.Numerics improvements:

https://news.ycombinator.com/item?id=34793453

This stuff is super exciting to me. I've been using the SIMD-accelerated numerics for a side-project.

.NET8 is also an LTS version, so we are going to be upgrading to this for our B2B product sometime this year or early next. We had to skip over 7 due to our constraints, so we will be going from 6=>8.