4 ms·
> 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. This strikes me as a prematur
by bangaladore 1y ago
> 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.
This strikes me as a premature optimization. Most use cases? I'm interested if you have any examples.
> Rust is a much better language for compiling to WASM.
Why's that?
- OtomotO 1y agoBecause Rust doesn't need a GC
- bangaladore 1y agohttps://developer.chrome.com/blog/wasmgc/ https://developer.chrome.com/blog/wasmgc/
- viraptor 1y agoBecause 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.
- pier25 1y ago> 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.html https://krausest.github.io/js-framework-benchmark/current.ht... Blazor uses 45x the memory compared to vanilla JS and up to 3000x the KBs.
- bangaladore 1y agoI 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.
- pier25 1y ago> 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 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_pwa_large_app_size_after_publish_is/ https://www.reddit.com/r/Blazor/comments/1kse00c/blazor_wasm...
- bangaladore 1y ago> 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.