I agree largely from a development perspective, but the client-side javascript frameworks are ultimately more performant, particularly on mobile, and are not as bad as they used to be. Neither server-side nor WASM are ideal for mobile devices. Downloading many megabytes of .NET dependencies for a WASM app is obscene compared to like 30 kilobytes for React.

It won't be megabytes, that's only in the experimental phase. Binaries can shrink dramatically once run through a linker and trimmed down to only used APIs.

As far as performant, I agree it wont matter in most trivial interactions but large datasets with computations already see an impact (for example we have million row datatables to show sometimes).

> Binaries can shrink dramatically once run through a linker and trimmed down to only used APIs.

It's worth pointing out that .NET Core has an assembly/executable generator that can package only the .NET libraries that are actually used.

Rust-based WASM front-end libraries will likely be small and also high performance. Unfortunately, all of the existing ones are highly experimental right now.

> “30 kilobytes for React” This is just not even close to being true.

The compressed size is 31 kb, and other frameworks are smaller.

https://gist.github.com/Restuta/cda69e50a853aa64912d

There's 3kb Preact with almost identical API.

So what's the other 27KB+ for?

Fiber, support fo async rendering, suspense, hooks. A different VDOM algorithm.

Better error handling and messaging...

With 5g that won't be an issue anymore...

Until they decide that 5g is good enough to allow them to ship the browser with every website. Net speeds have been increasing every year and yet the websites take longer to load.

In 2026 maybe...

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.