4 ms·

I'd suggest you re-read this[1] section of the article -- they're talking about "server-side generation" where rendering happens at compile time, not at request

by evnp 5y ago

I'd suggest you re-read this[1] section of the article -- they're talking about "server-side generation" where rendering happens at compile time, not at request time (to avoid delaying responses with on-the-fly render computation). The data you're referring to will not be available at compile time. [1] https://www.joshwcomeau.com/react/the-perils-of-rehydration/#server-side-rendering-101 https://www.joshwcomeau.com/react/the-perils-of-rehydration/...

msoad 5y ago
Yes, but how expensive it is to render on request time anyways? Is it really a better experience to send a "mostly accurate HTML" and "hydrate" it with JavaScript in client? I am working on this kind of technologies and I totally understand how it works but I'm not convinced this is the right solution. Actual rendering on edge without all this JS soup is what big websites should do.
- technobabbler 5y ago
  It's a cost thing... a lot easier to CDN static HTML files and only make edge calls as necessary. In our Next.js setup, for example, all pages are served static by default and cached around the world, but every revalidation period (60 seconds or so?), one edge worker will check the data source against the upstream CMS, and rebuild that one page if needed. That means our max edge worker and API call is 1 per minute, regardless of whether there are 10 visitors or 10 million. The others will just get the cached CDN files. That makes it a lot more affordable. If you had infinite budget and could pay for edge functions to re-render the page every visit, with or without caching, then more power to you. But not everyone can afford that. Edit: Also, a secondary benefit is accessibility. Since most of the content is served as a flat HTML, those with outdated browsers/misconfigured ad blockers/javascript turned off can still see the most important part of the content. Maybe they miss some interactivity, but they can still at least read the gist of the article since that's just HTML. Depending on your specific edge function configuration (i.e. whether it needs web workers or web sockets or such) some browsers may not load that correctly. Dangerous for that to be the only delivery mechanism. But if your edge function just masquerades as a web server and returns plain old HTTP, that shouldn't be a problem.
  - jennings_hunter 5y ago
    > In our Next.js setup, for example, all pages are served static by default and cached around the world, but every revalidation period (60 seconds or so?), one edge worker will check the data source against the upstream CMS, and rebuild that one page if needed. Are you all using the incremental static regeneration API to accomplish this?
    - technobabbler 5y ago
      > Are you all using the incremental static regeneration API to accomplish this? Yep. It's great, if hackish. A good overview (https://www.smashingmagazine.com/2021/04/incremental-static-regeneration-nextjs/ https://www.smashingmagazine.com/2021/04/incremental-static-...) or Vercel's own docs (https://vercel.com/docs/concepts/next.js/incremental-static-regeneration https://vercel.com/docs/concepts/next.js/incremental-static-...) Vercel aside, I think Cloudflare by itself works similarly if you configure it to "cache everything", including HTML pages, on a revalidation period. I find this a great balance between serverside rendering and static builds. Specifically it allows you to rebuild certain pages as things are created/updated (new or edit blog posts, products, etc.) without having to trigger a full rebuild every single time.
- bern4444 5y ago
  Remix [1] solves this problem very well. Data that is needed by a React component is declared in the same file as the component as a loader function which the server then invokes and renders into the component on the server so the client receives an HTML response with the view ready to go (server side rendering). I distinguish between server side rendering which is a function invocation that takes place for each request as opposed to pre built HTML which isn't "rendering" anything and instead returning a static, pre-generated file. With Remix, the client gets an HTML response the server generated with all the data it needs already retrieved (it was retrieved on the server). The client can then run any additional client side JS but the user doesn't need to wait on the client side JS to see the content they were trying to browse. Remix can easily be deployed to edge systems like cloudflare workers. The services that the loader functions hit can be run somewhere else of course as well. [1] remix.run
- handrous 5y ago
  My consistent experience is that sites that simply make a round trip to the server and re-render the world on every non-trivial interaction are much faster than "performant" web apps that try very hard never to request actual HTML from a server, ever.
mjlawson 5y ago
Personally, and I totally recognize that I'm likely arguing a moot point, I don't conflate static-site generation and server-side rendering and I don't think they can or should be used interchangeably as the author indicates. If my site can be hosted by Nginx alone, it's not server-side rendering to me. On the other hand, if I am paying for the overhead of running a node server to host my site, but it doesn't support this, why not? I'm very suspicious of the argument that it's to save time due to on-the-fly render costs. It seems that Remix and perhaps React's new server-side components will be solving this problem in a much more coherent way without requiring weird hacks like this.
- technobabbler 5y ago
  In the Next.js/Vercel world, this hybrid architecture is primarily (I believe) an issue of cost savings (for them and you). For $20/mo Vercel will host your hybrid Next.js side, yet do all of the backend configuration and maintenance on your behalf, configuring not just NPM but Lambda and Cloudflare Workers, along with nginx and caching and CDN mirroring and invalidations, all seamlessly. So as a dev you can just code against the Next.js docs and not have to play devops. That's a LOT of time savings for $20/mo, and you can afford way more page hits this way than a barebones $20/mo NPM VM would get you. Yes, backend it's super complex and fanned out to different providers, but Vercel manages all of that for you. I imagine Gatsby and Netlify are similar, but not sure. Next.js was designed around Vercel specifically (sadly) and there's a lot of vendor-specific lock-in features.
  - mjlawson 5y ago
    I completely get that this ease of configuration is a huge selling point. Yet I don't think that precludes the possibility of pre-loading information and injecting it at runtime. My main qualm here is probably one where the meaning behind terms like "server-side rendering" are drifting to favor artificial limitations imposed by framework providers. > Next.js was designed around Vercel specifically (sadly) and there's a lot of vendor-specific lock-in features. I ran into this while playing around with their middleware. It surprised me that native Node APIs weren't supported which significantly diminishes its utility.

by evnp 5y ago

msoad 5y ago

Yes, but how expensive it is to render on request time anyways? Is it really a better experience to send a "mostly accurate HTML" and "hydrate" it with JavaScript in client? I am working on this kind of technologies and I totally understand how it works but I'm not convinced this is the right solution. Actual rendering on edge without all this JS soup is what big websites should do.

technobabbler 5y ago
It's a cost thing... a lot easier to CDN static HTML files and only make edge calls as necessary. In our Next.js setup, for example, all pages are served static by default and cached around the world, but every revalidation period (60 seconds or so?), one edge worker will check the data source against the upstream CMS, and rebuild that one page if needed. That means our max edge worker and API call is 1 per minute, regardless of whether there are 10 visitors or 10 million. The others will just get the cached CDN files. That makes it a lot more affordable. If you had infinite budget and could pay for edge functions to re-render the page every visit, with or without caching, then more power to you. But not everyone can afford that. Edit: Also, a secondary benefit is accessibility. Since most of the content is served as a flat HTML, those with outdated browsers/misconfigured ad blockers/javascript turned off can still see the most important part of the content. Maybe they miss some interactivity, but they can still at least read the gist of the article since that's just HTML. Depending on your specific edge function configuration (i.e. whether it needs web workers or web sockets or such) some browsers may not load that correctly. Dangerous for that to be the only delivery mechanism. But if your edge function just masquerades as a web server and returns plain old HTTP, that shouldn't be a problem.
- jennings_hunter 5y ago
  > In our Next.js setup, for example, all pages are served static by default and cached around the world, but every revalidation period (60 seconds or so?), one edge worker will check the data source against the upstream CMS, and rebuild that one page if needed. Are you all using the incremental static regeneration API to accomplish this?
  - technobabbler 5y ago
    > Are you all using the incremental static regeneration API to accomplish this? Yep. It's great, if hackish. A good overview (https://www.smashingmagazine.com/2021/04/incremental-static-regeneration-nextjs/ https://www.smashingmagazine.com/2021/04/incremental-static-...) or Vercel's own docs (https://vercel.com/docs/concepts/next.js/incremental-static-regeneration https://vercel.com/docs/concepts/next.js/incremental-static-...) Vercel aside, I think Cloudflare by itself works similarly if you configure it to "cache everything", including HTML pages, on a revalidation period. I find this a great balance between serverside rendering and static builds. Specifically it allows you to rebuild certain pages as things are created/updated (new or edit blog posts, products, etc.) without having to trigger a full rebuild every single time.
bern4444 5y ago
Remix [1] solves this problem very well. Data that is needed by a React component is declared in the same file as the component as a loader function which the server then invokes and renders into the component on the server so the client receives an HTML response with the view ready to go (server side rendering). I distinguish between server side rendering which is a function invocation that takes place for each request as opposed to pre built HTML which isn't "rendering" anything and instead returning a static, pre-generated file. With Remix, the client gets an HTML response the server generated with all the data it needs already retrieved (it was retrieved on the server). The client can then run any additional client side JS but the user doesn't need to wait on the client side JS to see the content they were trying to browse. Remix can easily be deployed to edge systems like cloudflare workers. The services that the loader functions hit can be run somewhere else of course as well. [1] remix.run
handrous 5y ago
My consistent experience is that sites that simply make a round trip to the server and re-render the world on every non-trivial interaction are much faster than "performant" web apps that try very hard never to request actual HTML from a server, ever.

mjlawson 5y ago

Personally, and I totally recognize that I'm likely arguing a moot point, I don't conflate static-site generation and server-side rendering and I don't think they can or should be used interchangeably as the author indicates. If my site can be hosted by Nginx alone, it's not server-side rendering to me. On the other hand, if I am paying for the overhead of running a node server to host my site, but it doesn't support this, why not? I'm very suspicious of the argument that it's to save time due to on-the-fly render costs. It seems that Remix and perhaps React's new server-side components will be solving this problem in a much more coherent way without requiring weird hacks like this.

technobabbler 5y ago
In the Next.js/Vercel world, this hybrid architecture is primarily (I believe) an issue of cost savings (for them and you). For $20/mo Vercel will host your hybrid Next.js side, yet do all of the backend configuration and maintenance on your behalf, configuring not just NPM but Lambda and Cloudflare Workers, along with nginx and caching and CDN mirroring and invalidations, all seamlessly. So as a dev you can just code against the Next.js docs and not have to play devops. That's a LOT of time savings for $20/mo, and you can afford way more page hits this way than a barebones $20/mo NPM VM would get you. Yes, backend it's super complex and fanned out to different providers, but Vercel manages all of that for you. I imagine Gatsby and Netlify are similar, but not sure. Next.js was designed around Vercel specifically (sadly) and there's a lot of vendor-specific lock-in features.
- mjlawson 5y ago
  I completely get that this ease of configuration is a huge selling point. Yet I don't think that precludes the possibility of pre-loading information and injecting it at runtime. My main qualm here is probably one where the meaning behind terms like "server-side rendering" are drifting to favor artificial limitations imposed by framework providers. > Next.js was designed around Vercel specifically (sadly) and there's a lot of vendor-specific lock-in features. I ran into this while playing around with their middleware. It surprised me that native Node APIs weren't supported which significantly diminishes its utility.