Because rust actually compiles the code to native binaries. C# kind of started doing it some time ago, but AOT still has various limitations and edge cases. Blazor doesn't even compile your code into wasm - it ships the whole dotnet runtime as wasm and runs your app as bytecode. This means massive downloads regardless how simple your code is.

There's relatively recent AOT for Blazor, but even that has to ship all the managed DLLs and part of runtime for the runtime reflection / metadata support.

Because Rust doesn't need a GC

> Most use cases? I'm interested if you have any examples.

Basically anything isn't an in-house tool. Captive users don't have much of an alternative.

Blazor is specially bad for anything that is public and/or needs to run on mobile.

> This strikes me as a premature optimization

Avoiding shipping 10-20MB of WASM code is not premature optimization... it's just common sense.

I can agree that for C# teams it might be better to use Blazor but objectively JS/TS solutions are just better. Again, look at the objective hard data:

https://krausest.github.io/js-framework-benchmark/current.ht...

Blazor uses 45x the memory compared to vanilla JS and up to 3000x the KBs.

I don't use Blazor, but your point is still about solving a "problem" that might not exist.

> Avoiding shipping 10-20MB of WASM code

Do you have examples of this? I'm seeing more like 1-2 MB, and most of that is the runtime, which will be cached. This is very comparable to any other framework.

> Blazor uses 45x the memory compared to vanilla JS and up to 3000x the KBs.

Which doesn't matter unless it actually affects outcomes.

> I don't use Blazor, but your point is still about solving a "problem" that might not exist.

So you think a priori it's fine to shove MBs of code to a mobile user?

And, if you get into that situation with Blazor, what's the plan for solving the problem? Other than moving features to JS.

> Do you have examples of this?

I don't have any links at hand but the JS benchmarks I linked uses 4MB of uncompressed code (12MB with the AOT version) just for displaying a table and changing the data.

Here's a demo that's sending like 2MB of Blazor code for a button that updates some text:

https://blazor-demo.github.io/Counter

Here's someone using dotnet 9 reporting a 17MB download and 67MB with AOT:

https://www.reddit.com/r/Blazor/comments/1kse00c/blazor_wasm...

> So you think a priori it's fine to shove MBs of code to a mobile user?

I think we have to consider whether or not that matters.

> Here's a demo that's sending like 2MB of Blazor code for a button that updates some text:

Okay, but then what is the size increase if you have a full app? Is it 2MB per button (obviously not).

My point is you are so focused on things that may or may not matter. So saying its useless for most usecases is a terrible position.