5 ms·
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
by ablekh 6y ago
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.
- wyattpeak 6y agoIs 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.
- jolux 6y agoAre the latency issues specific to Blazor Server or are they inherent in any framework that uses this pattern, like LiveView?
- kumarvvr 6y agoInherent in any framework that uses a connection to transmit diffed DOM nodes.
- jolux 6y agoyeah, that's what I thought. it's certainly the achilles heel of this technique.
- resoluteteeth 6y agoIt 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.
- jolux 6y agoThe 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.
- kumarvvr 6y ago2 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.
- merlinscholz 6y agoWhile this may be true in most first world countries, 2mb are still a lot in development regions (and sadly also in Germany)
- ablekh 6y agoRemember, 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).
- jolux 6y agoDownload 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.
- ablekh 6y agoFair enough. Thank you for sharing your thoughts.
- mattferderer 6y agoI 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.
- ablekh 6y agoI 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 https://blog.ndepend.com/blazor-internals-you-need-to-know