Comment by hombre_fatal

(God why is this 8 paragraphs. This is what you get for being my first HN post of the day with a cuppa fresh coffee in hand. Shame on you for being the first post I saw while firmly rocking on my hobby horse.)

Dunno, the Next.js hybrid approach seems both trivial to understand the trade-offs of, but also optimal:

You get to use the same tooling, but if you don't use any of the dynamic stuff like the router (stuff you'd obviously need to use a server for), then you get to output static html files.

Or, you can start with an SSG site and then decide that you want server-side logic, and all you do is opt-in to some server-side logic.

This works well because instead of traditional SSGs like Jekyll, Next.js has the nice UX/DX of writing a dynamic server where it has a build step that crawls all your routes to generate static files (the right way to do SSG imo). So when you decide you want to run on a server, you just deploy it on the server instead of using the crawl step.

Framing this into a confusing subset vs superset distinction kinda obscures what's really going on. It's like writing an Express app but opting in to SSG by using a build tool that wget-crawls your local server.

The downside of Next.js is that client-side "rehydration" is inherently complex, not that it can enumerate your routes to generate static files. It's just that when you build a system that can render server html templates to strings and then rehydrate them in the browser, it's trivial to build the tool that saves those server templates into static html files.

And I think you're imagining that you could only do such a thing if you designed for it from the beginning, essentially bending over your abstraction to force that feature, when it's actually a trivial entailment of the system in the first place.