4 ms·

See, that's the problem: you said SSG can only take you as far as "something generic for everyone". This is not true, otherwise you could not implement static i

See, that's the problem: you said SSG can only take you as far as "something generic for everyone". This is not true, otherwise you could not implement static i18n. Also I don't want to squash them either but dynamic vs static is for instance much more appropriate, it's a shortcut for request-time vs build-time server rendering.

throwaway290 4y ago
What is generally meant by SSG is that at runtime you send fully usable static pages and don't need to run any app logic. This radically expands your options for hosting (S3 + CDN, done). You can't have personalization unless you run app servers, you can provide some alternatives at build time (localization, AB tests) but nothing actually personalized. Whereas with SSR you run an app aware server, which means you can store client state and do everything with it sending to the browser final HTML, but it is more costly. So to me and many others whether a framework can do SSR or SSG is a very important distinction, critical for infrastructure planning. I often see it being downplayed together with a promotion of various proprietary platforms offering edge computing but this stuff is just not necessary for many cases. Edit: No idea what terminology is used at NextJS, above is what I think is generally understood by SSG (static site) and SSR (server-rendered site).
- eric-burel 4y ago
  That's not Next wording, what you are describing seems to be an exported app (reintroduced in Next 13.3 via export output, and available in Next 12 via next export) SSG in Next is just pre-rendering some pages server-side at build-time, it's not so involved
Tehnix 4y ago
Static i18n is pretty easy to implement though? I’m Next.js I’ve previous solved it by making the chosen language part of the route. Sure, it generates more files, but that doesn’t really matter at all (cheap to host still, cheap to serve still). I could get behind static vs dynamic, but “server-side” has no meaning then to me, since there is no server/backend men at to be involved for the static part then (at least in my mental model of it).
- cies 4y ago
  Your static files still need a webserver. Maybe you do not need to write it, or configure it; but there is still one there. You probably just pay S3 or a CDN to do your web serving for you.
  - Tehnix 4y ago
    That is, practically speaking, an enormous difference though! Any CDN (CloudFront, CloudFlare, etc) coupled with any blob storage (S3 and others) vs the following: - Servers to run your node process - Load balancing to handle distributing traffic between several servers for your SSR’ed app How do you then run and update your servers? You now need to start thinking about zero-downtime rollouts, and grab something like ECS or the big hammer k8s. You can still handhold your own EC2 instances, but then you’re now home brewing a solution. The simplification of infrastructure that “static files” bring is not to be underestimated :)
    - eric-burel 4y ago
      There is always a server, CDN are servers, so even a totally static websites exported as HTML pages can benefit for user-level or segment-level personalization if the host has enough features. A simple URL rewriting layer is the only thing you need. Your mental model is consistent with what I see from Perseus, but I think that Next is already one step ahead, and this step is to understand that there is a always a server and a user request around even when you render statically. This was my initial point, probably poorly phrased.
      - Tehnix 4y ago
        > There is always a server, CDN are servers Sure, but in common parlance that’s not really a useful point. There are also servers involved in serverless, but we’ve largely accepted that here it is meant to indicate (on a gradient) who manages those servers :) When you set up your infrastructure, it will matter quite a lot whether you’re able to utilize a CDN as the only thing you need to deploy to, or if you need to run your own code at runtime (and hence need a something to run it on). It’s worth noting: You can absolutely go for all of these solutions! I do have a bit of a penchant for solutioning things that I know will scale up massively, but that is not always a priority early on, so I don’t want anyone to be discouraged by these approaches and the other benefits they can provide :) > there is always a server and a user request around even when you render statically I’d love to dive into that part a bit more, genuinely curious! Is the point that there is always dynamic information to act on to improve the user experience? Or what would be the goal or vision once you know that?

throwaway290 4y ago

What is generally meant by SSG is that at runtime you send fully usable static pages and don't need to run any app logic. This radically expands your options for hosting (S3 + CDN, done). You can't have personalization unless you run app servers, you can provide some alternatives at build time (localization, AB tests) but nothing actually personalized. Whereas with SSR you run an app aware server, which means you can store client state and do everything with it sending to the browser final HTML, but it is more costly. So to me and many others whether a framework can do SSR or SSG is a very important distinction, critical for infrastructure planning. I often see it being downplayed together with a promotion of various proprietary platforms offering edge computing but this stuff is just not necessary for many cases. Edit: No idea what terminology is used at NextJS, above is what I think is generally understood by SSG (static site) and SSR (server-rendered site).

eric-burel 4y ago
That's not Next wording, what you are describing seems to be an exported app (reintroduced in Next 13.3 via export output, and available in Next 12 via next export) SSG in Next is just pre-rendering some pages server-side at build-time, it's not so involved

Tehnix 4y ago

Static i18n is pretty easy to implement though? I’m Next.js I’ve previous solved it by making the chosen language part of the route. Sure, it generates more files, but that doesn’t really matter at all (cheap to host still, cheap to serve still). I could get behind static vs dynamic, but “server-side” has no meaning then to me, since there is no server/backend men at to be involved for the static part then (at least in my mental model of it).

cies 4y ago
Your static files still need a webserver. Maybe you do not need to write it, or configure it; but there is still one there. You probably just pay S3 or a CDN to do your web serving for you.
- Tehnix 4y ago
  That is, practically speaking, an enormous difference though! Any CDN (CloudFront, CloudFlare, etc) coupled with any blob storage (S3 and others) vs the following: - Servers to run your node process - Load balancing to handle distributing traffic between several servers for your SSR’ed app How do you then run and update your servers? You now need to start thinking about zero-downtime rollouts, and grab something like ECS or the big hammer k8s. You can still handhold your own EC2 instances, but then you’re now home brewing a solution. The simplification of infrastructure that “static files” bring is not to be underestimated :)
  - eric-burel 4y ago
    There is always a server, CDN are servers, so even a totally static websites exported as HTML pages can benefit for user-level or segment-level personalization if the host has enough features. A simple URL rewriting layer is the only thing you need. Your mental model is consistent with what I see from Perseus, but I think that Next is already one step ahead, and this step is to understand that there is a always a server and a user request around even when you render statically. This was my initial point, probably poorly phrased.
    - Tehnix 4y ago
      > There is always a server, CDN are servers Sure, but in common parlance that’s not really a useful point. There are also servers involved in serverless, but we’ve largely accepted that here it is meant to indicate (on a gradient) who manages those servers :) When you set up your infrastructure, it will matter quite a lot whether you’re able to utilize a CDN as the only thing you need to deploy to, or if you need to run your own code at runtime (and hence need a something to run it on). It’s worth noting: You can absolutely go for all of these solutions! I do have a bit of a penchant for solutioning things that I know will scale up massively, but that is not always a priority early on, so I don’t want anyone to be discouraged by these approaches and the other benefits they can provide :) > there is always a server and a user request around even when you render statically I’d love to dive into that part a bit more, genuinely curious! Is the point that there is always dynamic information to act on to improve the user experience? Or what would be the goal or vision once you know that?