From 5b06ae91decb6473cb974a77bcaedd8870fbd4bd Mon Sep 17 00:00:00 2001 From: Julian Schaefer Date: Fri, 20 Feb 2026 09:23:59 +0100 Subject: [PATCH 1/9] refactor: extract backlink component --- packages/docs/src/components/BackLink.astro | 21 +++++++++++++++++++ .../docs/src/components/FrameworkDetail.astro | 18 +++------------- 2 files changed, 24 insertions(+), 15 deletions(-) create mode 100644 packages/docs/src/components/BackLink.astro diff --git a/packages/docs/src/components/BackLink.astro b/packages/docs/src/components/BackLink.astro new file mode 100644 index 0000000..afc8421 --- /dev/null +++ b/packages/docs/src/components/BackLink.astro @@ -0,0 +1,21 @@ +--- + +--- + +← All frameworks + + diff --git a/packages/docs/src/components/FrameworkDetail.astro b/packages/docs/src/components/FrameworkDetail.astro index 377c14e..5703615 100644 --- a/packages/docs/src/components/FrameworkDetail.astro +++ b/packages/docs/src/components/FrameworkDetail.astro @@ -1,6 +1,8 @@ --- import type { CollectionEntry } from 'astro:content' import { formatBytesToMB, formatTimeMs } from '../lib/utils' +import '../styles/shared.css' +import BackLink from './BackLink.astro' import DevTimeChart from './DevTimeChart.astro' import MethodologyTag from './MethodologyTag.astro' import MethodologyNotes from './MethodologyNotes.astro' @@ -25,7 +27,7 @@ const measuredDateDisplay = (() => { ---
- ← All frameworks +
{devtime.name} @@ -193,20 +195,6 @@ const measuredDateDisplay = (() => { line-height: 1.5; } - .back-link { - display: inline-block; - margin-bottom: 1.5em; - color: var(--ft-accent); - text-decoration: none; - font-weight: 500; - transition: color 0.2s; - } - - .back-link:hover { - color: var(--ft-accent-hover); - text-decoration: underline; - } - .detail-header { margin-bottom: 2em; } From a42f32bcb1b5b65eeda561a50968c0bda8d31257 Mon Sep 17 00:00:00 2001 From: Julian Schaefer Date: Fri, 20 Feb 2026 09:46:38 +0100 Subject: [PATCH 2/9] feat: first draft of glossary page --- packages/docs/src/pages/glossary.astro | 258 +++++++++++++++++++++++++ 1 file changed, 258 insertions(+) create mode 100644 packages/docs/src/pages/glossary.astro diff --git a/packages/docs/src/pages/glossary.astro b/packages/docs/src/pages/glossary.astro new file mode 100644 index 0000000..4dadf78 --- /dev/null +++ b/packages/docs/src/pages/glossary.astro @@ -0,0 +1,258 @@ +--- +import BackLink from '../components/BackLink.astro' +import Layout from '../layouts/Layout.astro' +--- + + +
+ + +
+

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 ...

+ +

Partial Hydration

+

Partial Hydration is a technique where ...

+ +

Progressive Hydration

+

Progressive Hydration is a technique where ...

+ +

Streaming

+

Streaming is a rendering approach where ...

+ +

Incremental Static Regeneration (ISR)

+

ISR stands for Incremental Static Regeneration, which ...

+ +

Partial Prerendering (PPR)

+

Partial Prerendering is a rendering strategy where ...

+ +

Islands Architecture

+

Islands Architecture is a pattern where ...

+ +

Server Components (RSC)

+

Server Components are components that ...

+ +

Edge-Side Rendering (ESR)

+

Edge-Side Rendering is an approach where ...

+
+
+ + + From f18e84f356ff272e6d77f2903f9a8867d504bb8d Mon Sep 17 00:00:00 2001 From: Julian Schaefer Date: Fri, 20 Feb 2026 14:25:18 +0100 Subject: [PATCH 3/9] feat: add remaining glossary sections --- packages/docs/src/pages/glossary.astro | 101 ++++++++++++++++++++++--- 1 file changed, 90 insertions(+), 11 deletions(-) diff --git a/packages/docs/src/pages/glossary.astro b/packages/docs/src/pages/glossary.astro index 4dadf78..9b3fa26 100644 --- a/packages/docs/src/pages/glossary.astro +++ b/packages/docs/src/pages/glossary.astro @@ -137,31 +137,110 @@ import Layout from '../layouts/Layout.astro'

Hydration

-

Hydration is the process of ...

+

+ 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 ...

+

+ 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 is a technique where ...

+

+ 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. +

-

Streaming

-

Streaming is a rendering approach where ...

+

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 stands for Incremental Static Regeneration, which ...

+

+ 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 is a rendering strategy where ...

+

+ 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. +

-

Islands Architecture

-

Islands Architecture is a pattern where ...

+

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 ...

+

+ 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 is an approach where ...

+

+ 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. +

From 354d637dfda2955cba6f9869286689df4b45deaa Mon Sep 17 00:00:00 2001 From: Julian Schaefer Date: Mon, 23 Feb 2026 19:34:22 +0100 Subject: [PATCH 4/9] fix: minor fixes --- packages/docs/src/pages/glossary.astro | 19 ++----------------- 1 file changed, 2 insertions(+), 17 deletions(-) diff --git a/packages/docs/src/pages/glossary.astro b/packages/docs/src/pages/glossary.astro index 9b3fa26..aea8591 100644 --- a/packages/docs/src/pages/glossary.astro +++ b/packages/docs/src/pages/glossary.astro @@ -3,7 +3,7 @@ import BackLink from '../components/BackLink.astro' import Layout from '../layouts/Layout.astro' --- - +
@@ -280,20 +280,6 @@ import Layout from '../layouts/Layout.astro' } } - .detail-header { - margin-bottom: 2em; - } - - .detail-title { - font-size: 32px; - margin: 0 0 0.25em 0; - font-weight: 700; - background: var(--ft-gradient); - -webkit-background-clip: text; - -webkit-text-fill-color: transparent; - background-clip: text; - } - p, ul { font-size: 16px; @@ -309,8 +295,7 @@ import Layout from '../layouts/Layout.astro' h1 { font-size: 32px; - margin-top: 0.25em; - margin-bottom: 0.5em; + margin: 0 0 0.25em 0; font-weight: 700; background: var(--ft-gradient); -webkit-background-clip: text; From 224555801c0c7ebfbd66f5b10b75bf33ae5de9c3 Mon Sep 17 00:00:00 2001 From: Julian Schaefer Date: Mon, 23 Feb 2026 19:47:01 +0100 Subject: [PATCH 5/9] feat: add glossary to navbar --- packages/docs/src/components/Navbar.astro | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/packages/docs/src/components/Navbar.astro b/packages/docs/src/components/Navbar.astro index a68be63..6d1e268 100644 --- a/packages/docs/src/components/Navbar.astro +++ b/packages/docs/src/components/Navbar.astro @@ -20,6 +20,11 @@ const pathname = Astro.url.pathname class={`nav-link${pathname === '/run-time' ? ' nav-link--active' : ''}`} >Run Time + Glossary e18e.dev Blog From b24025c06b73f30942dc6630fb77c053e5031330 Mon Sep 17 00:00:00 2001 From: Julian Schaefer Date: Mon, 23 Feb 2026 19:52:40 +0100 Subject: [PATCH 6/9] style: harmonize maxwidth --- packages/docs/src/layouts/Layout.astro | 2 +- packages/docs/src/pages/framework/[slug].astro | 10 +--------- 2 files changed, 2 insertions(+), 10 deletions(-) diff --git a/packages/docs/src/layouts/Layout.astro b/packages/docs/src/layouts/Layout.astro index f35f3d1..1158897 100644 --- a/packages/docs/src/layouts/Layout.astro +++ b/packages/docs/src/layouts/Layout.astro @@ -69,7 +69,7 @@ const { title = 'Framework Tracker' } = Astro.props .page-content { width: 100%; - max-width: 1200px; + max-width: 900px; } @media screen and (max-width: 768px) { diff --git a/packages/docs/src/pages/framework/[slug].astro b/packages/docs/src/pages/framework/[slug].astro index 378e8e1..9b3b385 100644 --- a/packages/docs/src/pages/framework/[slug].astro +++ b/packages/docs/src/pages/framework/[slug].astro @@ -1,7 +1,7 @@ --- import { getCollection } from 'astro:content' -import Layout from '../../layouts/Layout.astro' import FrameworkDetail from '../../components/FrameworkDetail.astro' +import Layout from '../../layouts/Layout.astro' import { getFrameworkSlug } from '../../lib/utils' export async function getStaticPaths() { @@ -35,11 +35,3 @@ const { devtime, runtime, baseline } = Astro.props - - From b196da98754dc763ea8782a199818556ef2768b0 Mon Sep 17 00:00:00 2001 From: Julian Schaefer Date: Mon, 23 Feb 2026 19:53:12 +0100 Subject: [PATCH 7/9] refactor: use new layout and style structure --- .../docs/src/components/FrameworkDetail.astro | 2 - packages/docs/src/pages/glossary.astro | 548 ++++++++---------- packages/docs/src/styles/shared.css | 14 + 3 files changed, 247 insertions(+), 317 deletions(-) diff --git a/packages/docs/src/components/FrameworkDetail.astro b/packages/docs/src/components/FrameworkDetail.astro index 5703615..87f6ac6 100644 --- a/packages/docs/src/components/FrameworkDetail.astro +++ b/packages/docs/src/components/FrameworkDetail.astro @@ -5,8 +5,6 @@ import '../styles/shared.css' import BackLink from './BackLink.astro' import DevTimeChart from './DevTimeChart.astro' import MethodologyTag from './MethodologyTag.astro' -import MethodologyNotes from './MethodologyNotes.astro' -import '../styles/shared.css' import PageHeader from './PageHeader.astro' import SSRStatsMethodologyNotes from './SSRStatsMethodologyNotes.astro' diff --git a/packages/docs/src/pages/glossary.astro b/packages/docs/src/pages/glossary.astro index aea8591..586b3f7 100644 --- a/packages/docs/src/pages/glossary.astro +++ b/packages/docs/src/pages/glossary.astro @@ -1,322 +1,240 @@ --- import BackLink from '../components/BackLink.astro' +import PageHeader from '../components/PageHeader.astro' import Layout from '../layouts/Layout.astro' --- -
- - -
-

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. -

-
-
- - + + +
+ 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. +

+
diff --git a/packages/docs/src/styles/shared.css b/packages/docs/src/styles/shared.css index 1a8ae2c..855a94d 100644 --- a/packages/docs/src/styles/shared.css +++ b/packages/docs/src/styles/shared.css @@ -47,3 +47,17 @@ h3 { font-size: 18px; } } + +/* ── Section & paragraphs ─────────────────────────────────────── */ + +section { + margin-top: 2em; +} + +p, +ul { + font-size: 16px; + color: var(--ft-muted); + line-height: 1.6; + margin-bottom: 1em; +} From 80469e7b8c8bfad8b221b0a7664e2dc7e5f30881 Mon Sep 17 00:00:00 2001 From: Julian Schaefer Date: Mon, 23 Feb 2026 20:02:26 +0100 Subject: [PATCH 8/9] style: apply optimal line length readabilty https://baymard.com/blog/line-length-readability --- packages/docs/src/layouts/Layout.astro | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/docs/src/layouts/Layout.astro b/packages/docs/src/layouts/Layout.astro index 1158897..27101fb 100644 --- a/packages/docs/src/layouts/Layout.astro +++ b/packages/docs/src/layouts/Layout.astro @@ -69,7 +69,7 @@ const { title = 'Framework Tracker' } = Astro.props .page-content { width: 100%; - max-width: 900px; + max-width: 75ch; } @media screen and (max-width: 768px) { From 83a296a30460052650d8c64840b2726076085655 Mon Sep 17 00:00:00 2001 From: Julian Schaefer Date: Mon, 23 Feb 2026 20:05:40 +0100 Subject: [PATCH 9/9] style: add a link styles --- packages/docs/src/styles/shared.css | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/packages/docs/src/styles/shared.css b/packages/docs/src/styles/shared.css index 855a94d..a7a4346 100644 --- a/packages/docs/src/styles/shared.css +++ b/packages/docs/src/styles/shared.css @@ -61,3 +61,17 @@ ul { line-height: 1.6; margin-bottom: 1em; } + +a[href^='#'] { + color: var(--ft-accent); + text-decoration: none; + border-bottom: 1px solid transparent; + transition: + color 0.2s ease, + border-color 0.2s ease; +} +a[href^='#']:hover, +a[href^='#']:focus-visible { + color: var(--ft-accent); + border-bottom-color: var(--ft-accent); +}