5 ms·

Since the post mentions Next.js, it's worth calling out two streams of ongoing work that solve major painpoints of SSR: 1. A filesystem convention (`*.server.t

by Rauchg 4y ago

Since the post mentions Next.js, it's worth calling out two streams of ongoing work that solve major painpoints of SSR: 1. A filesystem convention (`*.server.ts`) for more cleanly separating client and server component trees 2. The introduction of a Web standards runtime[1] for SSR. If anything, we're entering the best generation of SSR ever. We'll see new generations of apps shipping less JS to the client, rendering and personalizing at the Edge, closer to the user, and the infrastructure to support this will be serverless and economically every efficient. [1] https://nextjs.org/docs/api-reference/edge-runtime https://nextjs.org/docs/api-reference/edge-runtime

nawgz 4y ago
Is it believed that you'll do less overall compute and bandwidth if you use serverless functions to execute (parts of your) client, in place of sending static bundles to the client and letting them execute it? I don't really get SSR. Isn't it more desirable to have more of the compute required to render the client done by the client machinery? I view this both as true in corporate and public web scenarios, surely it's cheaper to let the public render the SPA than it is to render it for them, surely in corporate this takes better advantage of already purchased machines with already installed programs instead of developer cycles wasted to recreate it, and surely it's better to have less server load and deployment complexity in both cases
- chrisco255 4y ago
  Not really, because any JS/HTML logic that you have needs to be downloaded into memory and compiled and interpreted by each client independently. Then, once loaded, any server-side data needs to be fetched from an API request and injected into the page in the proper place. Server-side rendering saves at least one round trip by fetching the data from the database and injecting it on the server side before sending the fully compiled HTML + CSS + JS as one static file. So you have to have some server-side logic regardless if you have the need for server-side data. The small amount of memory and compilation overhead by the server-side rendering function is more than made up for by the time saved on network latency. It's just not a significant amount of computation regardless. Importantly, the server-side is not loading a full DOM into memory before sending it down the pipe. It's just interpolating the resulting HTML/CSS/JS as if it were static after fetching the prerequisite data.
  - nawgz 4y ago
    > Not really, because any JS/HTML logic that you have needs to be downloaded into memory and compiled and interpreted by each client independently I see my question was unclear. I did not mean compute/bandwidth "in totality", I meant "in costs that would be invoked by the application owner". > Server-side rendering saves at least one round trip by fetching the data from the database and injecting it on the server side before sending the fully compiled HTML + CSS + JS as one static file. Sure, but the first hit would've been a cache hit anyways. > The small amount of memory and compilation overhead by the server-side rendering function is more than made up for by the time saved on network latency I don't really believe network latency would play in here. CDN would have the static bundle "at the edge" already for you. Static content is very easy to serve and break up into cacheable components for clients too, the Edge isn't really a revolution in that space. It's also unfair to present Edge functions as always-hot in terms of latency here, again I imagine the cost invoked for such features must be so high for so little gain
    - presentation 4y ago
      Yes it’s cheaper but also it’s a worse experience. It’ll take longer for a user’s crappy android phone to render your page from source than for a beefy cloud server on the edge to do the same.
      - nawgz 4y ago
        > It’ll take longer for a user’s crappy android phone to render your page from source than for a beefy cloud server on the edge to do the same. Yes, if you pay more money and integrate into cloud vendor systems, you can get more compute. Besides, the person with a crappy android is irrelevant to monetizing your application anyways, so their user experience is pretty irrelevant surely? I don't really understand the idea to spend money to improve the experience for people unlikely to spend money on your thing. And, again, the "beefy cloud server" experiences load from a shared user pool, so I doubt there's just flawless performance waiting for everyone all the time; if there is, surely you see "loss leader" written all over it.
- tored 4y ago
  If you look at it from a societal perspective SSR is better, it is easier to place servers closer to a clean energy source rather than every client.
- dbbk 4y ago
  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 of a mobile device. As soon as you have anyone visiting on a mobile device, and particularly on a mobile network, it's far superior to render it on the server.
  - nawgz 4y 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 4y 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 4y 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!

by Rauchg 4y ago

nawgz 4y ago

Is it believed that you'll do less overall compute and bandwidth if you use serverless functions to execute (parts of your) client, in place of sending static bundles to the client and letting them execute it? I don't really get SSR. Isn't it more desirable to have more of the compute required to render the client done by the client machinery? I view this both as true in corporate and public web scenarios, surely it's cheaper to let the public render the SPA than it is to render it for them, surely in corporate this takes better advantage of already purchased machines with already installed programs instead of developer cycles wasted to recreate it, and surely it's better to have less server load and deployment complexity in both cases

chrisco255 4y ago
Not really, because any JS/HTML logic that you have needs to be downloaded into memory and compiled and interpreted by each client independently. Then, once loaded, any server-side data needs to be fetched from an API request and injected into the page in the proper place. Server-side rendering saves at least one round trip by fetching the data from the database and injecting it on the server side before sending the fully compiled HTML + CSS + JS as one static file. So you have to have some server-side logic regardless if you have the need for server-side data. The small amount of memory and compilation overhead by the server-side rendering function is more than made up for by the time saved on network latency. It's just not a significant amount of computation regardless. Importantly, the server-side is not loading a full DOM into memory before sending it down the pipe. It's just interpolating the resulting HTML/CSS/JS as if it were static after fetching the prerequisite data.
- nawgz 4y ago
  > Not really, because any JS/HTML logic that you have needs to be downloaded into memory and compiled and interpreted by each client independently I see my question was unclear. I did not mean compute/bandwidth "in totality", I meant "in costs that would be invoked by the application owner". > Server-side rendering saves at least one round trip by fetching the data from the database and injecting it on the server side before sending the fully compiled HTML + CSS + JS as one static file. Sure, but the first hit would've been a cache hit anyways. > The small amount of memory and compilation overhead by the server-side rendering function is more than made up for by the time saved on network latency I don't really believe network latency would play in here. CDN would have the static bundle "at the edge" already for you. Static content is very easy to serve and break up into cacheable components for clients too, the Edge isn't really a revolution in that space. It's also unfair to present Edge functions as always-hot in terms of latency here, again I imagine the cost invoked for such features must be so high for so little gain
  - presentation 4y ago
    Yes it’s cheaper but also it’s a worse experience. It’ll take longer for a user’s crappy android phone to render your page from source than for a beefy cloud server on the edge to do the same.
    - nawgz 4y ago
      > It’ll take longer for a user’s crappy android phone to render your page from source than for a beefy cloud server on the edge to do the same. Yes, if you pay more money and integrate into cloud vendor systems, you can get more compute. Besides, the person with a crappy android is irrelevant to monetizing your application anyways, so their user experience is pretty irrelevant surely? I don't really understand the idea to spend money to improve the experience for people unlikely to spend money on your thing. And, again, the "beefy cloud server" experiences load from a shared user pool, so I doubt there's just flawless performance waiting for everyone all the time; if there is, surely you see "loss leader" written all over it.
tored 4y ago
If you look at it from a societal perspective SSR is better, it is easier to place servers closer to a clean energy source rather than every client.
dbbk 4y ago
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 of a mobile device. As soon as you have anyone visiting on a mobile device, and particularly on a mobile network, it's far superior to render it on the server.
- nawgz 4y 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 4y 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 4y 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!