> I'm of the opinion that this is the future of web development
Maybe but not with C#. Rust is a much better language for compiling to WASM. Leptos achieves something similar to Blazor with a fraction of the CPU and bytes.
I would love to be able to handle all my web stack with C# but unfortunately the WASM bundles are too heavy for most use cases. Plus the DX for frontend is not even as good as it was with JS and Webpack like a decade ago. And these days the bar is much higher with Vite.
Rust is unnecessarily low-level for the vast majority of things that a web app would be doing. There's no reason to struggle with the borrow checker in that kind of code when tracing GC is available and makes things so much easier.
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.
> 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:
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:
Maybe but not with C#. Rust is a much better language for compiling to WASM. Leptos achieves something similar to Blazor with a fraction of the CPU and bytes.
https://leptos.dev/
Blazor is much slower client-side than even the worse JS solution. Scroll to the right to see it compares:
https://krausest.github.io/js-framework-benchmark/current.ht...
I would love to be able to handle all my web stack with C# but unfortunately the WASM bundles are too heavy for most use cases. Plus the DX for frontend is not even as good as it was with JS and Webpack like a decade ago. And these days the bar is much higher with Vite.