3 ms·
I’d argue internal applications are _the only_ acceptable use case for Blazor. I only mention it because this quote from the article strikes me as mildly dising
by taejavu 6y ago
I’d argue internal applications are _the only_ acceptable use case for Blazor. I only mention it because this quote from the article strikes me as mildly disingenuous:
>
An app like this can basically scale forever, cheaply. It can put the browser to work (which was basically hanging out waiting for anglebrackets anyway)
>
It’s no more scalable than any other SPA framework as an Azure Static Web App, but it does require shipping a .Net runtime to every user. I’m surprised there’s rarely a mention of this important consideration in the discussions I’ve seen around Blazor.
- cm2187 6y agoMy understanding is that they do (or will do) some tree shaking to only transmit the bits of the runtime that are actually used. It's not like you will download a 60MB binary on every refresh. And it's not like a typical SPA doesn't come with its own bloat of js libraries. I do expect it so be slightly heavier. But to the point that a user will notice?
- taejavu 6y agoYep, and that's what the "2.5MB" in my original post referred to. So, a Blazor app that does nothing but print "Hello world" to the screen is as heavy as a horrendously bloated SPA that presumably does something of value. Yes the user will notice, just the same as they notice that horrendously bloated SPAs are slow.
- cm2187 6y agoBut that’s a slightly orthogonal problem. SPAs being misused is clearly an issue. A blog has no business being an SPA. But in the domains where SPAs make sense, I don’t know that it is going to be much heavier. Think webmail, online collaboration tools, trading platforms, etc.