Meta-framework Concepts

The stored prerendered copy, served immediately. The refreshed render runs outside that request and replaces the stored copy when it finishes, so only later visitors see the new HTML: nobody waits for the refresh, but whoever arrives during it gets the older page.

Prerendering at build time runs a route's data loading and render once, during the build, and writes the finished HTML into the build output. Every visitor is then served that same file, with no per-request fetch or render.

Hydration is a server-rendered route's second delivery: after the finished HTML paints, the browser downloads the component code and the data the server rendered with, then attaches behaviour to the existing markup instead of rebuilding it.

The browser receives a finished document: the framework matched the URL, ran that route's server-side data work and rendered markup before replying. Content is visible in the first paint, and machines that never run scripts can read it.

Input that arrives with the HTTP request and differs between callers: the cookie jar, request headers, the query string, the caller's address. Reading a database, a config value or a path parameter does not, by itself.

A file becomes a route only when its name matches the router's reserved route-module name, at its position under the routes directory; the folder chain becomes the URL. Every other file there is colocated code the router ignores.

A language in the path gives every translation its own address, so it can be linked, bookmarked, prerendered, crawled and cached as a distinct page. A cookie-only language makes one address return different text to different visitors.

Each matched route segment declares head entries as data. The framework collects them along the matched chain, merges them into one set, and writes that into the document head before the body, so every URL ships its own head.

It fetches a payload for only the route segments that differ between the current URL and the target — their data and, if missing, their code — then swaps those segments into the page that is already running.

Each matched path segment can contribute a route module, and the framework nests them outermost first: the top level renders the document shell, every level below renders inside its parent's slot, and the innermost module renders the page.

A copy kept on the server is shared: any request matching its key can be served it, including another visitor's. A copy in the browser tab is private to that browser and gone on a full page load.

Embedding the server's already-loaded result lets the browser's data cache start full, so the first client render reads it from cache instead of issuing a second request for data the user is already looking at.

A stored copy never learns that the data behind it changed. It becomes unusable only when the application names that copy and marks it stale, or when its freshness window elapses and the next request produces the value again.

A route's server-side data fetch runs when the URL matches, gathers the data that route needs, and hands it to the render, so the first HTML already carries the content and the browser needs no follow-up request.

A route-handled write is a server-side function the framework publishes at its own URL, so an ordinary HTML form can POST straight to it. The framework runs it on the server, then re-renders the route or follows a redirect.

Markup is output, not input - it never says which values produced it. The embedded payload hands the client the same data the server rendered from, so the client can rebuild the identical tree without scraping the DOM or refetching.

Running a route's server code near the user shortens only the network trip between browser and server. The work inside the handler takes the same time, and the distance from that code to its data usually gets longer.

The variable's name decides. The build substitutes into client code only names carrying a reserved public prefix, or names on an explicit allowlist; every other name is readable only in code that runs on the server.

A non-document route is a file in the same router tree that answers an HTTP request with JSON, a file, a stream or a redirect instead of an HTML page, sharing the pages' project, build and deployment.

A per-request interception step runs for every matching request before the framework resolves a route, renders it, or looks in its cache. It can continue, rewrite to another path, redirect, answer directly, or attach headers and cookies.

A deployment adapter translates one framework build into the exact shape a chosen host runs: a startable server entry, per-request function bundles, an edge bundle, or plain files plus routing rules. Same application code, different packaging.

A production build emits content-hashed client assets, prerendered documents for routes resolved at build time, a server bundle for routes that were not, and manifests mapping routes and assets to those files.

A development server compiles a route on demand and renders it again on every request, with prerendering skipped and the cache tiers switched off. The built output compiles once ahead of time and reuses whatever it is allowed to reuse.

A shared store keeps one copy of regenerated pages and cached data that every instance reads and writes, so all instances agree. Per-instance memory gives each process its own copy, and those copies drift apart.

A static export runs the build once and emits only files - HTML documents, JavaScript, CSS, media - with no server process behind them. The host's job is to map each URL to a file and return its bytes.