3 ms·

> Blazor is in development and will only get better. How good can it get though? Blazor WASM suffers from the huge initial, multi-megabyte download of the .NET

> Blazor is in development and will only get better. How good can it get though? Blazor WASM suffers from the huge initial, multi-megabyte download of the .NET runtime. How is that expected to come down to something in the range of 50-500kb what we have with most JS frameworks now? I just cannot do that on public-facing parts of an application. It is unusable when accessed from a slow mobile network. Company-internal stuff sure, who cares. I really wanted to love Blazor, and evaluated replacing some of the complex frontend UIs at work which are a JS nightmare with either Blazor Serverside or WASM. But serverside seems like an afterthought to me. I recently learned about Phoenix Liveview here on HN, and according to what I read, it seems like a much better option if you want that server-side rendering stream model. With Blazor-server, I get the feeling it is only a makeshift-solution until WASM takes off, and that makes me even more reluctant to use it.

rtpg 4y ago
I know that newer frameworks are slim but in practice bundles still seem pretty huge. Maybe that’s just asset bundling going on but I feel like people are still able to get away with.a lot
torginus 4y ago
While the total download size is unlikely to go below 2MB with Blazor due to .NET Framework binaries, they are working hard on AOT and binary stripping, meaning your app could consist of a base framework download, served from a CDN, and subsequently cached, and a small app specific library that's comparable to a bundled JS lib in size.
- cmroanirgo 4y ago
  >...served from a CDN, and subsequently cached Due to cache partioning in browsers now, this will still be a big issue for all clients. Don't also forget that many clients are in poor internet speed zones. A 2MB "buy in" will be unacceptably high for lots of projects (but not all, obviously).
JamesBarney 4y ago
I know I'm coming across ad a blazor fanboy, but I'm curious what made you feel like server side was an afterthought? The biggest way server side fucked us was originally db contexts are bound to scope via IOC in asp.net similar to MVC or razor pages. Which is fine when your scope is a single request, but when the scope is a circuit you get so many weird fucking errors. We worked around this by disabling tracking. But the right fix is we should have used factories, but we didn't figure this out until it was too late and we had written a fuck ton of code. This is such an obvious issue and should have been in the docs but wasn't. But other than that it seemed fined.
manigandham 4y ago
The vast majority of complex JS SPAs are also multi-megabyte payloads. You can also prerender components the same was SSR is used to mitigate JS initialization. As far server-side Blazor - it seems like an afterthought because you read about Phoenix Liveview? How is that a serious evaluation? Blazor is a core part of the framework now and the server-side model is always going to be a serious option because it enables functionality that can be done with the disconnected client/WASM mode (like direct DB access without the serialization + API overhead).
- Dave3of5 4y ago
  > The vast majority of complex JS SPAs are also multi-megabyte payloads I suspect you're talking about full apps that include third party deps. The majority of SPAs are < 1MB unzipped and <150KB zipped. Source: https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d You can't look at some site that has 10MB of third party deps and compare that to what Blazor is doing. You'll still need third party deps with Blazor as well. The sites that have a large 10MB bundle would have had 100's of 100KB scripts pre-spa days.

rtpg 4y ago

I know that newer frameworks are slim but in practice bundles still seem pretty huge. Maybe that’s just asset bundling going on but I feel like people are still able to get away with.a lot

torginus 4y ago

While the total download size is unlikely to go below 2MB with Blazor due to .NET Framework binaries, they are working hard on AOT and binary stripping, meaning your app could consist of a base framework download, served from a CDN, and subsequently cached, and a small app specific library that's comparable to a bundled JS lib in size.

cmroanirgo 4y ago
>...served from a CDN, and subsequently cached Due to cache partioning in browsers now, this will still be a big issue for all clients. Don't also forget that many clients are in poor internet speed zones. A 2MB "buy in" will be unacceptably high for lots of projects (but not all, obviously).

JamesBarney 4y ago

I know I'm coming across ad a blazor fanboy, but I'm curious what made you feel like server side was an afterthought? The biggest way server side fucked us was originally db contexts are bound to scope via IOC in asp.net similar to MVC or razor pages. Which is fine when your scope is a single request, but when the scope is a circuit you get so many weird fucking errors. We worked around this by disabling tracking. But the right fix is we should have used factories, but we didn't figure this out until it was too late and we had written a fuck ton of code. This is such an obvious issue and should have been in the docs but wasn't. But other than that it seemed fined.

manigandham 4y ago

The vast majority of complex JS SPAs are also multi-megabyte payloads. You can also prerender components the same was SSR is used to mitigate JS initialization. As far server-side Blazor - it seems like an afterthought because you read about Phoenix Liveview? How is that a serious evaluation? Blazor is a core part of the framework now and the server-side model is always going to be a serious option because it enables functionality that can be done with the disconnected client/WASM mode (like direct DB access without the serialization + API overhead).

Dave3of5 4y ago
> The vast majority of complex JS SPAs are also multi-megabyte payloads I suspect you're talking about full apps that include third party deps. The majority of SPAs are < 1MB unzipped and <150KB zipped. Source: https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d You can't look at some site that has 10MB of third party deps and compare that to what Blazor is doing. You'll still need third party deps with Blazor as well. The sites that have a large 10MB bundle would have had 100's of 100KB scripts pre-spa days.