6 ms·

I always thought of static sites as prebuilt from templates, whereas traditional SSR sites populate the templates (think jsp or php) on demand. Depending on the

I always thought of static sites as prebuilt from templates, whereas traditional SSR sites populate the templates (think jsp or php) on demand. Depending on the framework, the SSR page might already be cached and be effectively static.

eric-burel 4y ago
Yes seeing it as a cache, where the cache key is a transformation of the user request (including requests to "static" pages) is a better model that leads to a unified vision of SSR/SSG
- anonymous_sorry 4y ago
  I get that you can see it that way. If you were going to use server-side rending (SSR) anyway you can claim that static site generation (SSG) is a special case supported by any SSR framework. Or perhaps even that SSR is a generalisation of SSG to support dynamic content. But it feels like a bit of a stretch. The whole point of SSG is to simplify your architecture and tooling by forgoing the ability to dynamically render content on the server. It is a trade-off that won't be suitable for every application, and that's absolutely fine. If you want to argue that SSR tooling can be so simple and cheap that the SSG trade-off isn't worth it, then I'm keen to learn about that. But to elide the distinction between the two seems unhelpful to me.
  - eric-burel 4y ago
    I mean the framework can of course differientiate those use cases clearly, static and dynamic still exist in Next 13 App Router. But making them totally separate is a mistake too. Namely what bothers me is that a few points made in the docs or by users in this comment section show a limited visions of static rendering. It is certainly not limited to generic content that is the same for all users, I've built enough counter-examples to prove it.
    - anonymous_sorry 4y ago
      Why is it a mistake to separate them? If can generate my site as a bunch of static content, upload it to a server, and have it served by nginx or similar, then I don't need to think about the next.js App Router, React, or indeed any custom server-side code. That's what static site generation is for, and it seems rather distinct from what you are talking about. Yes it is limiting, and it won't be appropriate for many use cases. But if you can do it, it makes things simpler, cheaper and more efficient. That's not to say you can't combine SSG tooling with dynamic content too if you need it. But static-only is a perfectly valid choice if you can get away with it.
      - eric-burel 4y ago
        Your answer conflates statically rendering a page (server-side prerendering at build-time), and statically rendering a website (exporting in Next.js terminology). You seem to talk about statically rendering the website while my point is more about statically rendering pages or layouts.
re-thc 4y ago
Anything that has to go through a server is not effectively static. If you live in Tokyo and connect to a website in Oregon, this effectively static could be ~100ms (served by origin) vs actual static that's ~10ms (served by CDN local PoP). Side note: this is why developers need to care about infrastructure and vice versa. I distinctly dislike the abstract separations as the implementation details always matter.
- aww_dang 4y ago
  Latency issues for the round trip are a different topic. Static means unchanging. In this context, pre-rendered pages stored in HTML files. CDNs may inject dynamic content into the page or filter the request, but this is a digression.
- eric-burel 4y ago
  That's also why you can render user specific content statically, you just need to redirect the user to the right page, for instance using an URL rewrite

eric-burel 4y ago

Yes seeing it as a cache, where the cache key is a transformation of the user request (including requests to "static" pages) is a better model that leads to a unified vision of SSR/SSG

anonymous_sorry 4y ago
I get that you can see it that way. If you were going to use server-side rending (SSR) anyway you can claim that static site generation (SSG) is a special case supported by any SSR framework. Or perhaps even that SSR is a generalisation of SSG to support dynamic content. But it feels like a bit of a stretch. The whole point of SSG is to simplify your architecture and tooling by forgoing the ability to dynamically render content on the server. It is a trade-off that won't be suitable for every application, and that's absolutely fine. If you want to argue that SSR tooling can be so simple and cheap that the SSG trade-off isn't worth it, then I'm keen to learn about that. But to elide the distinction between the two seems unhelpful to me.
- eric-burel 4y ago
  I mean the framework can of course differientiate those use cases clearly, static and dynamic still exist in Next 13 App Router. But making them totally separate is a mistake too. Namely what bothers me is that a few points made in the docs or by users in this comment section show a limited visions of static rendering. It is certainly not limited to generic content that is the same for all users, I've built enough counter-examples to prove it.
  - anonymous_sorry 4y ago
    Why is it a mistake to separate them? If can generate my site as a bunch of static content, upload it to a server, and have it served by nginx or similar, then I don't need to think about the next.js App Router, React, or indeed any custom server-side code. That's what static site generation is for, and it seems rather distinct from what you are talking about. Yes it is limiting, and it won't be appropriate for many use cases. But if you can do it, it makes things simpler, cheaper and more efficient. That's not to say you can't combine SSG tooling with dynamic content too if you need it. But static-only is a perfectly valid choice if you can get away with it.
    - eric-burel 4y ago
      Your answer conflates statically rendering a page (server-side prerendering at build-time), and statically rendering a website (exporting in Next.js terminology). You seem to talk about statically rendering the website while my point is more about statically rendering pages or layouts.

re-thc 4y ago

Anything that has to go through a server is not effectively static. If you live in Tokyo and connect to a website in Oregon, this effectively static could be ~100ms (served by origin) vs actual static that's ~10ms (served by CDN local PoP). Side note: this is why developers need to care about infrastructure and vice versa. I distinctly dislike the abstract separations as the implementation details always matter.

aww_dang 4y ago
Latency issues for the round trip are a different topic. Static means unchanging. In this context, pre-rendered pages stored in HTML files. CDNs may inject dynamic content into the page or filter the request, but this is a digression.
eric-burel 4y ago
That's also why you can render user specific content statically, you just need to redirect the user to the right page, for instance using an URL rewrite