From 59afbcffb1c982409d8cfc81eb4f485f4b7a6d84 Mon Sep 17 00:00:00 2001 From: Julian Schaefer Date: Fri, 20 Feb 2026 09:23:59 +0100 Subject: [PATCH 1/3] refactor: extract backlink component --- packages/docs/src/components/BackLink.astro | 21 +++++++++++++++++++ .../docs/src/components/FrameworkDetail.astro | 19 +++-------------- 2 files changed, 24 insertions(+), 16 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 c42fa4d..06bcc33 100644 --- a/packages/docs/src/components/FrameworkDetail.astro +++ b/packages/docs/src/components/FrameworkDetail.astro @@ -1,8 +1,9 @@ --- import type { CollectionEntry } from 'astro:content' import { formatBytesToMB, formatTimeMs } from '../lib/utils' -import DevTimeChart from './DevTimeChart.astro' import '../styles/shared.css' +import BackLink from './BackLink.astro' +import DevTimeChart from './DevTimeChart.astro' interface Props { devtime: CollectionEntry<'devtime'>['data'] @@ -20,7 +21,7 @@ const measuredDateDisplay = (() => { ---
- ← All frameworks +

{devtime.name}

@@ -220,20 +221,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 4310574332fdcd2c13716b0c0beb465960845306 Mon Sep 17 00:00:00 2001 From: Julian Schaefer Date: Fri, 20 Feb 2026 09:46:38 +0100 Subject: [PATCH 2/3] 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 b9159d1c62efec63fbb4d91e8bb41ae5f259ccf3 Mon Sep 17 00:00:00 2001 From: Julian Schaefer Date: Fri, 20 Feb 2026 14:25:18 +0100 Subject: [PATCH 3/3] 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. +