3 ms·
I think you're talking past each other: the problem isn't assuming the client's internet is fast, the problem is assuming the client's internet is stable. If y
by hnbad 4y ago
I think you're talking past each other: the problem isn't assuming the client's internet is fast, the problem is assuming the client's internet is stable.
If you replace most interactions that could be resolved client-side with a network transaction, you're betting on the client's internet being not just reasonably fast but also very stable. When I'm on the go, my internet is more likely to be fast than stable.
- hu3 4y ago> The problem is assuming the client's internet is stable. Yep. This is the major drawback of backend-dependent interactions. This is what scares me away from amazing technologies such as ASP.NET Core Blazor Server where I can code my frontend in C# instead of JavaScript. If only Blazor Wasm wasn't so heavy. 4mb of runtime DLLs is a bit off-putting to any use but intranet LOB applications.
- Ducki 4y agoRecent versions trimmed it down to about 1mb.
- wwweston 4y agoYour comment dovetails with my primary point: how an app serializes or renders data is entirely trivial compared to planning for network availability issues when it comes to app function and user experience. GP asks: "is it ever acceptable to round-trip to the server to re-render a component that could have been updated fully-client side?" This is a question that's oriented around what is generated on the server and pushed over the wire rather than the fact that there is a network call at all. If the network is not stable, a typical 1st-load-heavy SPA-framework will make... a tenuous network call returning JSON with iffy chances of success instead of a tenuous network call returning an HTML fragment with iffy chances of success.