[bob1029]

> - enables offline/low bandwidth use of your app with automatic state syncing and zero UX degradation

> would you do it?

No, because the "automatic state syncing and zero UX degradation" is a "draw the rest of the owl" exercise wherein the specific implementation details are omitted. Everything is domain specific when it comes to sync-based latency hiding techniques. SSR is domain agnostic.

> low bandwidth requirements

If we are looking at this from a purely information theoretical perspective, the extra 50kb gzipped is starting to feel kind of heavy compared to my ~8kb (plaintext) HTML response. If I am being provided internet via avian species in Africa, I would also prefer the entire webpage be delivered in one simple response body without any dependencies. It is possible to use so little javascript and css that it makes more sense to inline it. SSR enables this because you can simply use multipart form submissions for all of the interactions. The browser already knows how to do this stuff without any help.

[horsawlarway]

I just want to point out that your argument is now contradictory.

You're stating that networks and latency will only improve, and that this is a reason to prefer SSR.

You're also stating that 50kb feels too heavy.

But at 8kb of SSR'd plaintext, you're ~6 page loads away from breaking even with the 50kb of content that will be cached locally, and you yourself are arguing that the transport for that 50kb is only getting better.

Basically: you're arguing it's not a problem to duplicate all the data for the layout on every page load because networks are good and getting better. But also arguing that the network isn't good enough to load a local-first layout engine once, even at low multiples of your page size.

So which is it?

---

Entirely separate of the "rest of the owl" argument, with which I agree.

[samdoesnothing]

> the extra 50kb gzipped is starting to feel kind of heavy compared to my ~8kb (plaintext) HTML response

I thought we were living in a utopia where fast high-speed internet was ubiquitous everywhere? What's the fuss over 50kb? 5mb should be fine in this fantasy world.

[TimTheTinker]

> "automatic state syncing and zero UX degradation" is a "draw the rest of the owl" exercise

That's an assumption you're making, but that doesn't necessarily have to be true. I offered you what amounts to a magic button (drop this script in, done), not a full implementation exercise.

If it really were just a matter of dropping a 50kb script in (nothing else) would you do it? Where's the size cutoff between "no" and "yes" for you?

> Everything is domain specific when it comes to sync-based latency hiding techniques.

Yes and no. To actually add it to your app right now would most likely require domain-specific techniques. But that doesn't imply that a more general technique won't appear in the future, or that an existing technique can't be sufficiently generalized.

> the extra 50kb gzipped is starting to feel kind of heavy

Yeah - but we can reasonably assume it's a one-and-done cached asset that effectively only has to be downloaded once for your app.

[nchmy]

And when your avian ISP dies, how do you make requests?

If everything you need - application logic, css, media, data etc... - is cached on your device, you can carry on.

You're being far too myopic about all of this. There's many different use cases and solutions, all of which have their tradeoffs. Sometimes ssr is appropriate, other times local first is. You can even do both - SSR html in the service worker with either isomorphic JavaScript, or WASM.

We can all agree, though, that React and it's derivations are never appropriate.