Re:If Not SPAs, What?
by ablekh on Wednesday October 28, 2020 @09:00PM
(#24925953)
Blazor is certainly a very interesting and promising piece of technology. However, Blazor Server hosting mode is prone to latency issues and requires always-on connection to run an applications (so, no offline mode). On the other hand, the alternative Blazor WebAssembly mode requires clients to download a sizeable mix of .NET runtime and other system DLLs on the first use of the application (even a lightweight demo application with almost zero app-specific resources requires a download of 6+ MB of data in DEBUG mode and 2+ MB in RELEASE mode). Of course, relevant Microsoft teams work hard on further minimizing the size of the system bundle, but there are obvious limits to efforts in this regard.
[ Parent
| on HN ]
Is offline mode widely used? I remember it being released to great excitement and then I never heard about it again. I assumed it died out when being offline became too much of an edge-case for your average user to be worth dealing with.
I have no idea about how widely used the offline mode is, but I'm curious to find out, should people run across relevant statistics.
I would describe it as more of a "tail end" case, a small percentage of use cases, but a long list of users.
Re:If Not SPAs, What?
by mattferderer on Wednesday October 28, 2020 @10:52PM
(#24926611)
I believe the runtime is under 1 MB before compression. As you stated, they're working hard to reduce that size.
At the same time, while not condoning it, I just scrolled to the bottom of Amazon's front page and downloaded over 30 MB.
I think that "under 1 MB" represents the size of .NET runtime proper. However, additional required system DLLs increase the download size of a minimal application to the numbers I cited above [1]. Anyway, your example of Amazon's front page is interesting and is a good point (even though, in my quick test out of curiosity, relevant download size resulted in 2.2 MB [not authenticated] and 9.2 MB [authenticated] - quite a bit less, but still ...).
[1] https://blog.ndepend.com/blazor-internals-you-need-to-know
2 MB should not be an issue nowadays. Considering 5G roll out & substantial coverage in most mature markets, in say, 2 - 3 years, 2 MB is acceptable.
Remember, that 2+ MB is the download size of a bare-bones application. Relevant sizes for real-world applications, obviously, would be bigger (though, depending on the total size, the Blazor part might or might not be essential).
Download sizes are definitely a problem but they’re not really a Blazor-specific issue these days. Also I would be curious to learn about the relative density of JavaScript bloat vs Blazor download sizes because the .NET class library is much more feature rich before adding dependencies and I could imagine bundle sizes actually being smaller for similar functionality above a certain point. But you’re right that it’s probably never going to get as small as a pure HTML + CSS app with progressive enhancement and minimal JavaScript.
Fair enough. Thank you for sharing your thoughts.
Re:If Not SPAs, What?
by merlinscholz on Wednesday October 28, 2020 @10:51PM
(#24926599)
While this may be true in most first world countries, 2mb are still a lot in development regions (and sadly also in Germany)
Are the latency issues specific to Blazor Server or are they inherent in any framework that uses this pattern, like LiveView?
Re:If Not SPAs, What?
by resoluteteeth on Wednesday October 28, 2020 @10:09PM
(#24926334)
It doesn't seem like there's any major difference so it's interesting that latency is perceived as being a reason not to use blazor server in production but not as such with liveview.
The audience for Blazor Server is probably an order of magnitude larger than the audience for LiveView, and it's mostly not the Hacker News crowd that needs to be won over, but the large enterprise with half a million lines of Web Forms that has grown into an unmaintainable behemoth.
Inherent in any framework that uses a connection to transmit diffed DOM nodes.