4 ms·

> you start making the assumption that the client's internet is fast. The most common trajectory for react and other SPA framework apps is to also make this as

> you start making the assumption that the client's internet is fast. The most common trajectory for react and other SPA framework apps is to also make this assumption, waving away the weight of libraries and front-end business logic with talk of how build tools are stripping out unused code so it must be light, while frequently skipping affordances for outright network failure that the browser handles transparently, oh and hey don't forget to load it all up with the analytics calls. But maybe more crucially: what's the real difference between the overhead of generating / delivering markup vs JSON? They're both essentially data structure -> string serialization processes. JSON is situationally more compact but by a rough factor that places most components on the same order of magnitude. And rendered markup is tautologically about the data necessary to render. Meanwhile JSON payloads may or may not have been audited for size. Or if they have, frequently by people who can't conceive of any other solution than graphql front-end libraries. Whether you push html or json or freakin' xml over the wire is a red herring. Heck, "nativeness" might be a red herring given frequent shortcomings in native apps themselves -- so many of them can't operate offline in spite of the fact that should be their strength because native devs ALSO assume client's internet is fast/on.

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 ago
    Recent versions trimmed it down to about 1mb.
- wwweston 4y ago
  Your 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.
lf-non 4y ago
It may be common when starting out, but we do have paths to optimize out of it. We can do code splitting, eager fetching js when page is idle, optimistic rendering when page is taking time etc. Unlike what a lot of people like to believe not every spa runs 20 megs of js on page load. Also the initial load time being a few seconds and then the app being snappy and interactive is an acceptable compromise for a lot of apps (not everything is an ecommerce site). When most fragments need to be server rendered it manifests as a general slowness throughout the interaction lifecycle that you can't do much about without adopting different paradigm. The hey-style service-worker based caching hits clear boundaries when the ui is not mostly read only and output of one step very closely depends on the previous interactions. I joined a place working on larger rails+unpoly+stimulus app which started off as server rendered fragments with some js sprinkled in, but after two years had devolved into a spaghetti where to figure out any bug I'd typically need to hunt down what template was originally rendered, whether or not it was updated via unpoly, whether or not what unpoly swapped in used the same template as the original (often it was not), whether or not some js interacted with it before it was swapped, after it was swapped etc. .... all in all I felt like if you push this to use cases where lot of interactivity is needed on the client, it is better to opt for a framework that provides more structure and encapsulation on the client side. I am sure good disciplined engineers will be able to build maintainable applications with these combinations, but in my experience incrementally optimizing a messy spa app is generally more straightforward than a server-rendered-client-enhanced mishmash. ymmv.
- ricardobeat 4y ago
  > Unlike what a lot of people like to believe not every spa runs 20 megs of js on page load This is not a new take, it's exactly what every die-hard SPA dev says. While 20MB is an exaggeration, the average web page size has ballooned in the past decade from ~500KB in 2010 to around 4MB today. And the vast majority of those pages is just text, there is usually nothing really interactive in them that would require a client-side framework. Others will say 2MB, 4MB is not that bad, but that just shows how far out of touch with the reality of mobile internet they are. Start measuring the actual download speeds your users are getting and you'll be terribly disappointed even in major urban centers.
mrcus 4y ago
On a transatlantic flight I recently had the displeasure of browsing over a satellite connection. A lot of sites simply never loaded, even though the connection speed was reasonable. The multi-second latency made these sites that loaded tens to hundreds of resources completely unable to render a single character to screen.

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 ago
  Recent versions trimmed it down to about 1mb.
wwweston 4y ago
Your 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.

lf-non 4y ago

It may be common when starting out, but we do have paths to optimize out of it. We can do code splitting, eager fetching js when page is idle, optimistic rendering when page is taking time etc. Unlike what a lot of people like to believe not every spa runs 20 megs of js on page load. Also the initial load time being a few seconds and then the app being snappy and interactive is an acceptable compromise for a lot of apps (not everything is an ecommerce site). When most fragments need to be server rendered it manifests as a general slowness throughout the interaction lifecycle that you can't do much about without adopting different paradigm. The hey-style service-worker based caching hits clear boundaries when the ui is not mostly read only and output of one step very closely depends on the previous interactions. I joined a place working on larger rails+unpoly+stimulus app which started off as server rendered fragments with some js sprinkled in, but after two years had devolved into a spaghetti where to figure out any bug I'd typically need to hunt down what template was originally rendered, whether or not it was updated via unpoly, whether or not what unpoly swapped in used the same template as the original (often it was not), whether or not some js interacted with it before it was swapped, after it was swapped etc. .... all in all I felt like if you push this to use cases where lot of interactivity is needed on the client, it is better to opt for a framework that provides more structure and encapsulation on the client side. I am sure good disciplined engineers will be able to build maintainable applications with these combinations, but in my experience incrementally optimizing a messy spa app is generally more straightforward than a server-rendered-client-enhanced mishmash. ymmv.

ricardobeat 4y ago
> Unlike what a lot of people like to believe not every spa runs 20 megs of js on page load This is not a new take, it's exactly what every die-hard SPA dev says. While 20MB is an exaggeration, the average web page size has ballooned in the past decade from ~500KB in 2010 to around 4MB today. And the vast majority of those pages is just text, there is usually nothing really interactive in them that would require a client-side framework. Others will say 2MB, 4MB is not that bad, but that just shows how far out of touch with the reality of mobile internet they are. Start measuring the actual download speeds your users are getting and you'll be terribly disappointed even in major urban centers.

mrcus 4y ago

On a transatlantic flight I recently had the displeasure of browsing over a satellite connection. A lot of sites simply never loaded, even though the connection speed was reasonable. The multi-second latency made these sites that loaded tens to hundreds of resources completely unable to render a single character to screen.