Glossary
++ This site describes the terminology and concepts used in the framework + tracker. +
+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. +
+