Meta-frameworks (SSR/SSG)

It is a Route Segment Config export that forces the route to be rendered on the server for every request instead of being prerendered, so its HTML is never served out of Next's Full Route Cache.

No scheduler is involved. The number is a staleness window in seconds: after 3600 seconds the cached page is merely marked stale, and only the next incoming request for that route causes Next.js to regenerate it.

Next.js reads a single middleware file at the project root, next to app/ (or inside src/). Exporting config.matcher restricts which request paths invoke it; with no matcher, the middleware function runs for every request the app serves.

NextResponse.rewrite serves a different route internally: the browser keeps the original URL and makes one request. NextResponse.redirect returns a 3xx with a Location header, so the browser makes a second request and the address bar changes.

A route.ts file turns its folder's path into an HTTP endpoint. You export one async function per HTTP method, named exactly GET, POST, PUT, PATCH, DELETE, HEAD or OPTIONS, and Next.js answers 405 Method Not Allowed for any method you did not export.

Nuxt 4 auto-imports Vue APIs like ref, its own composables like useState, components from app/components/, and the exports of top-level files in app/composables/ and app/utils/. The build injects real imports only where a file uses those names.

useFetch and useAsyncData fetch during server rendering and ship the result in the Nuxt payload, so hydration reuses it instead of refetching. A bare $fetch in setup runs on the server and again in the browser; keep $fetch for user-triggered calls.

In Nuxt 4, app/pages/index.vue serves /, app/pages/recipes/index.vue serves /recipes and app/pages/recipes/[slug].vue serves /recipes/lemon-tart. That page reads the segment through the auto-imported useRoute(): route.params.slug is 'lemon-tart'.

With Nuxt 4's default ssr: true, each request gets server-rendered HTML plus a payload for hydration. ssr: false sends a shell with an empty #__nuxt root for the browser to fill. nuxt generate prerenders pages into static HTML files at build time.

Both folders hold Nitro handlers exported with defineEventHandler. Files in server/api are served under /api, files in server/routes at the bare path; brackets in a file name become parameters and a .get or .post suffix limits the method.

AnalogJS is a Vite-based meta-framework for Angular. It adds file-based pages, per-page server load functions, API routes built by Nitro, and prerender and deployment options, while Angular itself still renders, routes and hydrates the app.

In AnalogJS, only .page.ts files under src/app/pages become routes: (home).page.ts is /, blog/[slug].page.ts is /blog/:slug, a file beside a same-named folder is a layout, a (group) folder adds no segment, and [...page-not-found].page.ts is the ** route.

In AnalogJS, an async load exported from catalogue.server.ts runs only on the server and returns JSON-serialisable data. Analog resolves it before the page component is created, and the component reads it with injectLoad<typeof load>(), usually wrapped in toSignal.

In AnalogJS, a file like src/server/routes/api/newsletter.post.ts that default-exports an h3 defineEventHandler becomes POST /api/newsletter. Nitro compiles it into Analog's server output, so it exists only where that server runs, never in a static-only build.

In AnalogJS, list the blog URLs in prerender.routes, leave the catalogue to the default ssr: true, and set nitro.routeRules { '/admin/**': { ssr: false } } so admin pages render only in the browser.

VitePress compiles each Markdown file into a Vue component, prerenders every page to static HTML at build time, then hydrates it into a single-page app. A minimal project is Markdown pages plus .vitepress/config, run with vitepress dev and build.

Add a <script setup> block after the frontmatter, import the demo component and use its tag in the Markdown. Keep component names PascalCase or hyphenated, remember code fences are v-pre, and prefer <style module> to <style scoped>.

Import the demo file as a code block with <<< @/demos/ButtonBasic.vue, group the npm, pnpm and yarn fences in a ::: code-group container, and add a ::: warning container. Frontmatter such as outline and editLink tunes the page.

vitepress dev renders only in the browser, but build prerenders in Node. <ClientOnly> delays rendering until mount, yet the library still touches window when it is imported. Load it after mount with defineClientComponent or a dynamic import.

vitepress build fails when an internal Markdown link points to no page, unless ignoreDeadLinks allows it. cleanUrls: true drops .html from links, so the host must serve /foo.html for /foo; base: '/nimbus-ui/' prefixes every root-relative link.

useForm holds the form's fields in data, updates them through setData, and submits them as an Inertia visit with put, post or patch; processing stays true while that visit runs, and errors fills with one message per field when Laravel validation fails.

Inertia::render returns an Inertia\Response that becomes a page object: component, props, url and version. A normal browser request gets the root Blade view with that object embedded as JSON; a request sending X-Inertia: true gets the bare object as JSON.

Inertia remounts the page component on each visit, so a layout rendered inside the page is destroyed with it; declaring the layout on the component (Page.layout) lets Inertia render it outside the page, so the same layout instance and its player state survive.

Laravel treats the Inertia visit as a normal form post: validation failure redirects back with errors flashed to the session, and on the follow-up request the Inertia middleware shares them as the always-included errors prop, which the client routes to onError.

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.