How does a framework that infers a route's rendering mode differ from one that makes the route declare and enforce it?

## The same question, two ways of answering it Every meta-framework that can prerender has to decide, per route, whether one output can serve everyone or the render must run per request. There are two ways to arrive at that answer, and they produce completely different developer experiences when someone gets it wrong. ## The inference model Here the mode is a **consequence**, not a setting. The framework renders the route, watches what it touches, and classifies it: read nothing request-bound and the output is kept as a prerendered copy; read a cookie, a header, the query string or the caller's address and the route is reclassified as per-request. - It is **zero-ceremony**: the correct mode falls out of the code, and adding personalisation just works. - It is **silent**: nothing errors when a route leaves the static set, because from the framework's point of view the developer asked for personalisation and got it. - It is **transitive and whole-tree**: the read can be in a shared layout, a utility module, or a third-party component, and it still counts. - The evidence lives in the **build output** — a per-route table or manifest saying which routes were prerendered — and in production signals such as a jump in origin requests. The characteristic failure is therefore a **regression you did not notice**: a route that used to be a cached file is now a render per view, and the symptom is latency, load or cost, weeks later. ## The declaration model Here the route states its promise — prerender this, render this per request — and the framework **holds it to that promise**. Reading request-bound input inside a route declared static is an error, surfaced at one of two moments: 1. **At build time**, while the framework prerenders the route: the render throws, and the build fails with the offending read named. 2. **At render time**, when the route is produced or revalidated in production: the request fails, or the framework logs and degrades, depending on the implementation. - It is **loud**: the person who introduces the read is the person who sees the failure. - It is **explicit documentation**: reading the route tells you what it promises without running a build. - It costs **friction**: a legitimate change now needs two edits, and teams under time pressure learn to flip the declaration to per-request rather than think about whether they should. - It usually needs **escape hatches** — a way to say "this part is allowed to be per-request" — and those hatches are where the subtlety hides. ## Comparing the two | | Inference | Declaration | |---|---|---| | Who decides | The render, by what it touched | The route, up front | | When a mistake surfaces | Later, as cost or staleness | Immediately, as a failure | | Where you look | Build output, origin traffic | The error message | | Typical failure | Silent flip to per-request | A build that will not finish | | Risk | Drift nobody notices | Declarations flipped to silence the error | Many real frameworks sit between the two: they infer by default but accept a per-route override that declares the intent, and the override is what turns a silent flip into an error. That hybrid is the most common shape in practice, and it is worth saying so rather than presenting the models as a clean dichotomy. ## Why the distinction is practical, not academic It changes your first move when a page misbehaves. - In an **inference** framework, a page that is suddenly slow or uncacheable is a search problem: diff the build output across commits to find when the route left the prerendered set, then bisect the render tree for the read that did it. - In a **declaration** framework, the same mistake never reaches production as a silent regression; instead you triage a failing build, and the risk you manage is people weakening declarations to get green. It also changes how you review. Under inference, the reviewable artefact is the *diff of which routes are static*, which is why teams snapshot the build's route table and fail CI when a route leaves the set. Under declaration, the reviewable artefact is the declaration change itself — a one-line diff that deserves the same scrutiny as a schema change. ## The honest summary Inference optimises for writing the code; declaration optimises for keeping a promise over years and many hands. Neither is safer on its own: an inferred route with a snapshot test in CI behaves like a declared one, and a declared route whose declaration is edited without thought behaves like an inferred one.