Pre-rendering should not necessarily happen at build-time

[eric-burel]

Hi,

Lately, I've worked a lot on formalizing the concepts of server-side rendering, be it at build-time or request-time (link here, be careful that's a hard read and only a first draft).

Currently, "pre-rendering" is defined at rendering at build-time specifically. However, I think it'd be interesting to broaden up this definition. For instance, rendering at request-time and putting the result into a cache is a form of pre-rendering, Next.js Incremental Static Regeneration being the first implementation of this approach. I believe we might see similar features emerge in existing frameworks in the long run.

I've opened the subject on Next.j Discord and the very first feedback I had was that pre-rendering should include any form of server-rendering, so basically defining pre-rendering as "any rendering that doesn't happen on the end user machine".

This definition would be focused more on the user experience more than the developer experience, who thinks in terms of build-time/request-time.

For instance the change could be as simple as "With Jamstack, the entire front end is prebuilt into highly optimized static pages and assets , usually during a build process." => usually, because there might be alternative hybrid approaches, like building only demanded pages, or caching request-time renders etc.

What's your opinion on this?

Edit: see Next.js definition as well, that considers 2 forms of pre-rendering.

[philhawksworth]

Hey @eric-burel. I really like how you evolve the Jamstack definition there. I like this increased focus an explicitness. Food for though for sure!

Regarding the term "pre-render" I don't quite agree. Let me see if I can explain why:

defining pre-rendering as "any rendering that doesn't happen on the end user machine".

That definition would suggest that any traditional server which generated a response on demand (cached or not) would be "pre-generating". Like PHP, ASP, and .net stacks. "Pre-generating" was intended to describe the opposite.

In my opinion, a critical factor on why pre-rendering can have advantages is that not just that it happens somewhere other than on the client's machine, but also that it does not happen as a result of a request for that view.

The "pre" part of the word suggests that it happens ahead of when it is needed. This decoupling is a critical piece of de-risking the system.

Generating a response on-demand and then caching it for future isn't really pre-rendering since it is happening as a direct result of the first request, and if it fails, it fails for that request and all subsequent requests. This model is common in the traditional tech stacks and architectures that Jamstack tries to be an alternative too.

Generating at build time means that "your mistakes don't leave the kitchen". They are decoupled from the requests.

Does that make sense?

Also — apologies for the slow response. My bad! I'd love to have these types of discussions in the new Jamstack Discord, and we'd love to see you there!

[eric-burel]

No problem, it took me a lot of time to mature this work as well ^^ I've updated the article (https://tinyurl.com/ssr-theory) a lot since, the latest version being from last November.

Your definition definitely does make sense of course, I simply wanted to point that from a different point of view you may end up to call other things "pre-rendering" as well, in the sense of "pre-rendering on the server instead of rendering dynamically on the client", the "pre" being relative to the client-side rendering and not to the request.

Nowadays I would tend to have this categorization:

• CSR: client-side rendering => so I make it clear that all other forms of rendering are implicitly server-side rendering
• BTR: build-time rendering => what you call "pre-rendering" here, aka static rendering. With indeed the key specificity that the render happens before the website is live, contrary to other forms of rendering
• RTR: request-time rendering => which includes traditional server language as well as modern approaches that relies a lot on the cache like Next.js Incremental Static Regeneration

This way I avoid the confusion of "pre-rendering" => I directly clarify the "build moment". I also avoid "server-side rendering", which is very ambiguous, probably because in the early days of SSR it was always request-time rendering and we didn't have static frameworks such as Hugo, then Gatsby etc.

It's also a bit more open to intermediate strategies. Like when you use Next.js ISR, but you fire a few requests automatically, to warm some pages or force their rerender at a controlled period of time, you are doing a kind "on-demand rendering", in between build-time and request-time. If you have really a lot of pages, you could do "intelligent rendering", by emptying/pre-filling the render cache based on the estimated demand for content, at moment computed by an algorithm or a set of rules. Example: you render and cache content specific to some countries only during their day time.

I'll definitely join the Discord, I have a few more things to share, namely "rainbow rendering" and the "megaparam pattern" in Next.js :)