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

bangaladore · 2025-09-23T21:40:49 1758663649

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.

pier25 · 2025-09-23T22:12:49 1758665569

> 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...

bangaladore · 2025-09-24T18:51:17 1758739877

> 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.