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).

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

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).

An URL rewrite doesn't involve making the language part of the route. It's true that you use a route parameter, but the user doesn't have to see it. Look for Segmented Rendering or the Megaparam pattern for my work on this idea.

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.

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 :)

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.

> 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?

I am mostly thinking about personalization (AB tests, i18n, marketing segment, multi-tenancy belongs to this family of use cases), it's often assumed that you can't achieve personalization with static rendering, and that's just not true: a simple (read very fast, very cheap, optimized for this use case, like CDN are supposed to be) URL rewriting server can point to the right statically rendered page at request time. Another approach is modifying the page at the edge, Eleventy does that. All this involve being aware that your static content will be accessed using an HTTP request, taking that into account may lead to a more unified (not squashed though, just unified) SSR/SSG architecture similar to Next 13 one. You can look for Plasmic take on AB tests with Next or my own work on Segmented Rendering or the "megaparam" pattern.