+ This site describes the terminology and concepts used in the framework + tracker. +
++ MPA (Multi-Page Application) and + SPA (Single-Page Application) + are the two foundational architectures for web applications. The choice between + them shapes how pages are rendered, how navigation works, and how state is managed. + In practice, many modern frameworks blur the line by supporting hybrid approaches + — for example, combining server-rendered pages with client-side navigation. +
+The key aspects that distinguish an application architecture are:
++ In an MPA, each navigation triggers a full browser request and the server + responds with a complete HTML document. HTML is generated on the server + per request, so the browser always receives ready-to-display content. + JavaScript is optional and typically used only for progressive + enhancement. In-memory state is lost on every navigation. Because content + is present in the initial HTML response, MPAs are naturally SEO-friendly. + The server must be capable of rendering and serving a full page for every + route. +
+ ++ In an SPA, the browser loads a single HTML shell once and all subsequent + navigation is handled client-side by JavaScript, without full page + reloads. HTML is generated in the browser, typically by a JavaScript + framework rendering components on demand. On initial load the browser + receives a minimal document and must download and execute JS before + content appears. Subsequent navigations fetch only data (e.g. via API + calls), keeping the page transition fast. In-memory state persists across + navigation. Because the initial HTML shell contains little content, SPAs + require extra effort (SSR, prerendering) for good SEO. The server only + needs to serve static assets. +
++ A rendering pattern describes how and when content is generated and + delivered to the client, typically the browser. The rendering process can + happen on the client or on a server, and at different stages of the + application lifecycle. +
++ Each pattern has different tradeoffs in terms of performance, SEO, UX, + resource usage, robustness, and complexity. The choice of rendering + pattern can have a significant impact on the overall experience and + maintainability of the application. +
+ ++ All pages are pre-built into static HTML files at build time (ahead of + time) by a build tool or framework. The output is a set of ready-to-serve + files — one per route — that can be delivered directly from a CDN with no + server needed at runtime. Because every response is a pre-built file, load + times are fast and infrastructure is simple. Best suited for content that + doesn't change per request. +
+ ++ HTML is generated on a server for each incoming request (just in time). + This allows dynamic content and per-request logic such as authentication, + personalization, or A/B testing. Unlike SSG, SSR requires a running server + at runtime. +
++ The term SSR is often used together with + hydration. However, classic SSR works without + hydration — the server sends functional HTML that relies on native browser + capabilities (links, forms) rather than a JavaScript framework. This is + the traditional web model where JavaScript is only used for progressive + enhancement, not for rendering core content. +
+ ++ Instead of receiving ready-made HTML from a server, the browser receives a + minimal HTML skeleton and a JavaScript bundle. The JS framework then + fetches data, builds the DOM, and controls all rendering on the client + side. +
++ This enables highly dynamic interfaces where the page can update without + full reloads. The tradeoff is a slower initial load — nothing meaningful + appears until the JavaScript has downloaded and executed — and weaker SEO + by default, since the initial HTML response contains little content. +
+ ++ Hydration is the process of making server-rendered HTML interactive on the + client. After the browser receives the static HTML produced by + SSR, a JavaScript framework re-attaches event handlers, + restores component state, and wires up reactivity — turning an inert + document into a fully interactive application. During hydration the + framework typically re-executes the component tree against the existing + DOM rather than replacing it. +
++ What happens after hydration depends on the + application architecture. For a + SPA, once hydration completes the JavaScript framework + takes over routing and rendering — subsequent navigations are handled + client-side. In MPA setups, hydration only activates specific + components without changing the navigation model - page transitions still trigger + full server requests. +
++ The tradeoff is that hydration requires downloading and executing the same + component code that was already run on the server, which can delay + interactivity on slow devices or large pages. Techniques like + partial hydration, + progressive hydration, and + islands architecture aim to reduce this cost. +
+ ++ Partial hydration is a technique where only specific components on a page + are hydrated on the client, rather than hydrating the entire component + tree. Static parts of the page remain as plain HTML and never load any + JavaScript, while interactive components are selectively hydrated. This + reduces the amount of JavaScript the browser needs to download, parse, and + execute. +
+ ++ Progressive hydration defers the hydration of individual components until + they are actually needed, rather than hydrating everything at once on page + load. Components can be hydrated based on triggers such as the component + scrolling into the viewport, the browser becoming idle, or the user + interacting with the component for the first time. This spreads the cost + of hydration over time. +
+ ++ Islands architecture is a pattern where interactive UI components — called + "islands" — are hydrated independently within an otherwise static HTML + page. The static content is rendered at build time or on the server with + zero JavaScript, and only the islands ship client-side code. Each island + hydrates on its own, without depending on a top-level application shell. +
+ ++ ISR is a hybrid of SSG and SSR + where statically generated pages are regenerated in the background after a configured + time interval or on-demand trigger, without requiring a full site rebuild. When + a request arrives for a stale page, the cached version is served immediately + while a fresh version is generated in the background for subsequent requests. +
+ ++ Partial prerendering splits a single route into a static shell that is + served instantly and dynamic holes that are streamed in at request time. + The static parts of the page — any content known at build time — are + prerendered and cached, while personalized or data-dependent sections are + rendered on-demand and streamed into the page via Suspense boundaries. +
+ ++ Streaming is a rendering approach where server-rendered HTML is sent to + the browser in chunks as each part becomes ready, rather than waiting for + the entire page to finish rendering. The browser can begin parsing and + displaying content as soon as the first bytes arrive, improving + time-to-first-byte and perceived performance. +
+ ++ Server Components are components that execute exclusively on the server. + Unlike traditional SSR, where component code is sent to + the client for hydration, Server Components send + only their rendered output — never their source code — to the client. They + can directly access server-side resources such as databases and file + systems without exposing those details to the browser. +
+ ++ Edge-side rendering moves the rendering step from a central origin server + to edge servers distributed geographically close to the user. Instead of + every request traveling to a single data center, the nearest edge node + renders the HTML, reducing latency and improving time-to-first-byte. +
+