Early on any project now, usually before anyone has drawn a diagram, I ask a question that is not about which framework we are using or how the content will be managed but something plainer: does this page have one correct output, or one per reader? The answer takes a minute to work out for any given page and it decides more of the architecture than most of the decisions that get discussed at length.
We have written before about how language belongs in the URL for documents and in the user's profile for applications, which is the same split applied to addressing. This note applies it one layer down, to rendering, where the consequences are larger and the temptation to pick one model for everything is stronger.
What Server Rendering Does That Generation Cannot
I want to start on the side that our own tooling does not emphasize, because the honest case for request-time rendering is not that it is more modern or more flexible in some vague way but that there are properties it has which pre-rendering cannot have at all, and they are worth naming precisely rather than gesturing at.
The first is that the output depends on who is reading. Not a variant of the output, not a translated version of it, but a genuinely different document per person, since an account page shows one person's orders and another person's orders and these are not two renderings of the same page but two different pages that happen to share a template. Pre-rendering here is not slow, it is undefined, because there is no such thing as the finished output of a page whose content is a function of the reader.
The second is freshness measured in seconds rather than in editions. A seat map for a concert, a stock level during a sale, a queue position, a balance after a transfer: these are correct for a moment and wrong shortly after, and no publishing cadence solves that, because the problem is not that the edition is old but that the concept of an edition does not fit data which changes while the reader is looking at it.
The third is that the read can be part of something the reader just did. When somebody submits a form and lands on a page showing the result, the render is a step in a transaction rather than a document being fetched, and it has to reflect a write that happened moments ago in the same session, which is a sequencing requirement that no cache can be talked into satisfying.
The fourth, and the one I find teams underestimate most often, is that authorization frequently decides content rather than access. It is easy to think of permissions as a gate in front of a page, which is a model that pre-rendering can live with, but in real operational software the same route shows different sections to different roles, and at that point the render is a security boundary. A rendering model that produces one artifact for everyone and relies on the client to hide what should not be seen is not a performance decision, it is a vulnerability with good response times.
These are not preferences. They are properties, and a page that needs any of them cannot be an edition no matter how the delivery is arranged.
The Question, and Why It Is Not "How Dynamic Is This?"
The usual way this decision gets made is by asking how dynamic the content is, and that question is unreliable because it measures the wrong thing. A news homepage changes many times a day and is perfectly publishable, while a settings page might change twice a year and can never be published at all, so the frequency of change tells you almost nothing about which model applies.
What sorts it correctly is whether the page has one correct output at a given moment, or one per reader, which is a question about identity rather than about volatility. If two people load the same URL and should see the same thing, the page is a document, and the only remaining question is how often the presses run. If they should each see their own version, the page is not a document at all but a view onto their data, and it belongs to the application from the beginning.
The URL post arrived at a nearly identical test from a different direction, which was whether two people who share a link should see the same content or each see it their way, and I do not think the resemblance is a coincidence. Both are asking whether the thing has an identity independent of its reader, since that is the property that determines whether it can be addressed, indexed, cached, published, archived, and quoted, or whether it can only be rendered for somebody.
Most Products Are Both
Where this gets practical, and where the most expensive mistakes happen, is that the majority of what we are asked to build turns out to be a publication with an application living inside it, so the failure is rarely a wrong model and almost always one model applied to the whole thing.
A booking system for a community centre is the shape I meet most often. The pages describing the rooms, the pricing, the opening hours, the directions, the accessibility information: those are documents, they have one correct output, people find them through search engines and share them in emails, and they should be published as editions. The page where somebody sees their own reservations is not a document under any reading, and neither is the administrator's view of tomorrow's schedule. The same product, one domain, two rendering models, and the reason to be deliberate about it is that the failure modes point in opposite directions.
Treat the whole thing as an application and you have made the room descriptions unfindable, slower than they need to be, and dependent on an origin being awake, for no benefit whatsoever, since nothing about a room description varies by reader. Treat the whole thing as a publication and you will find yourself building elaborate client-side machinery to fetch the parts that could not be pre-rendered, which is server rendering with extra steps and worse ergonomics, arriving eventually at a page that is static in name and dynamic in behavior.
This is the same reasoning behind the subdomain split in the URL post, and in practice the boundary usually falls in the same place, since the pages that deserve localized addresses are almost exactly the pages that deserve to be published as editions. When a project has a clean seam like that, the architecture gets simpler on both sides of it, because each side can be wholeheartedly what it is instead of being a compromise that half serves two purposes.
Why We Default to Publication
Our default is to treat a page as a document until something forces otherwise, and I want to be clear that this is a default rather than a conviction about what the web should be, because in-house operational software is a large part of what we build and almost none of it is publishable.
The reason for the default is that the properties listed at the start of this note are demanding, and a page that does not need any of them gets nothing from being rendered on request. A room description that is generated once and published costs nothing to serve, works when the origin is down, can be archived and quoted, and has no cold path, so choosing request-time rendering for it means accepting an origin, a cache, an invalidation strategy, and a set of failure modes in exchange for a flexibility the page will never use.
But the same reasoning runs in reverse and deserves saying with equal weight, since a page whose output depends on the reader gains nothing from being forced toward publication, and attempts to force it there produce the worst architecture of the three, where the shell is published, the substance arrives later by fetch, and the page is neither a document nor an honest application. When we find ourselves adding client-side machinery to work around the fact that a page cannot be pre-rendered, we take it as a signal that the page was an application surface all along and we were arguing with it.
Deciding Per Page, Not Per Project
The practical shape of all this is that the decision belongs to the page rather than to the project, and that a product is allowed to contain both kinds without that being a compromise or a sign of indecision.
What we do is go through the routes early and sort them by the question at the top, which usually produces a clear majority of documents, a small set of genuine application surfaces, and a handful of pages where reasonable people would disagree. The disputed ones tend to be personalized-but-not-private, like a page showing recently viewed items or a regional variant, and for those the useful follow-up is whether the personalization is content or decoration, since a document with a small personalized ornament can still be published with the ornament filled in by the client afterwards, while a page whose substance is personal cannot.
Getting this sorted early is worth more than it sounds, because the cost of discovering three months in that a section of the product needed the other model is not the rendering change itself but everything built on top of the assumption, and that is the kind of rework which arrives at exactly the moment a project has no room for it.