Glossary

Application architecture

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:

• Navigation model — Does the browser perform a full page load for each route (MPA), or does JavaScript intercept navigation and update the page in-place (SPA)?
• Content loading and processing — Is HTML assembled on the server and sent ready-to-display (MPA), or is it generated in the browser by a JavaScript framework consuming raw data fetched from an API (SPA)?
• State lifetime — Is in-memory state reset on every navigation (MPA), or does it persist across route changes within the same session (SPA)?
• JavaScript dependency — Is JavaScript required for the page to be meaningful, or is it an optional progressive enhancement on top of server-rendered HTML?
• SEO and initial load — Is content present in the first HTML response (MPA), or does meaningful content only appear after JS downloads and executes (SPA)?

Multi-Page Application (MPA)

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.

Single-Page Application (SPA)

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.

Rendering Patterns

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.

Static Site Generation (SSG)

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.

Server-Side Rendering (SSR)

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.

Client-Side Rendering (CSR)

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

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

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

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

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.

Incremental Static Regeneration (ISR)

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 (PPR)

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

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 (RSC)

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 (ESR)

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.