3 ms·

Doing something fully on the client is a nice idea, if your users all have fast connections, high processing power, and are all visiting from a desktop instead

• nawgz 5y ago
  You're right, it's a far superior pattern to waste tons of dev cycles to enable your team to give money to AWS so AWS can execute the logic their device would already do, just so your initial page load is 50% faster and your app otherwise performs identically, except the huge stutter step when you try to hydrate the state to match what your server rendered, which looks like hot garbage. HN is not full of front-ends, I can tell that much.
  • dbbk 5y ago
    Your viewpoint is valid but it's a philosophical argument, not a pragmatic one. I'm also not sure what you mean by 'stutter step'. I would posit that 95% of visitors never even notice hydration.
    • nawgz 5y ago
      > Your viewpoint is valid but it's a philosophical argument, not a pragmatic one. I think not locking yourself to specific cloud architectures is quite pragmatic, but to each their own. > stutter step SSR advocates: parsing JS and interacting takes way too long, it's so noticeable and terrible! Me: so if you serve a pre-rendered-via-SSR page AND a bundle of interactivity, there's going to be a nice set of static content that will be uninteractable during that entire terribly long parsing and loading phase? SSR advocates: Never heard of such a thing, parsing JS and getting interactivity is instant!