Skip to content

Commit 4310574

Browse files
TheiazTheiaz
committed
feat: first draft of glossary page
1 parent 59afbcf commit 4310574

1 file changed

Lines changed: 258 additions & 0 deletions

File tree

‎packages/docs/src/pages/glossary.astro‎

Lines changed: 258 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,258 @@
1+
---
2+
import BackLink from '../components/BackLink.astro'
3+
import Layout from '../layouts/Layout.astro'
4+
---
5+
6+
<Layout title="Glossary page">
7+
<main>
8+
<BackLink />
9+
10+
<header>
11+
<h1 class="detail-title">Glossary</h1>
12+
<p>
13+
This site describes the terminology and concepts used in the framework
14+
tracker.
15+
</p>
16+
</header>
17+
18+
<section>
19+
<h2 id="application-architecture">Application architecture</h2>
20+
<p>
21+
<strong>MPA (Multi-Page Application)</strong> and
22+
<strong>SPA (Single-Page Application)</strong>
23+
are the two foundational architectures for web applications. The choice between
24+
them shapes how pages are rendered, how navigation works, and how state is
25+
managed. In practice, many modern frameworks blur the line by supporting hybrid
26+
approaches — for example, combining server-rendered pages with client-side
27+
navigation.
28+
</p>
29+
<p>The key aspects that distinguish an application architecture are:</p>
30+
<ul>
31+
<li>
32+
<strong>Navigation model</strong> — Does the browser perform a full page
33+
load for each route (MPA), or does JavaScript intercept navigation and update
34+
the page in-place (SPA)?
35+
</li>
36+
<li>
37+
<strong>Content loading and processing</strong> — Is HTML assembled on the
38+
server and sent ready-to-display (MPA), or is it generated in the browser
39+
by a JavaScript framework consuming raw data fetched from an API (SPA)?
40+
</li>
41+
<li>
42+
<strong>State lifetime</strong> — Is in-memory state reset on every navigation
43+
(MPA), or does it persist across route changes within the same session (SPA)?
44+
</li>
45+
<li>
46+
<strong>JavaScript dependency</strong> — Is JavaScript required for the
47+
page to be meaningful, or is it an optional progressive enhancement on top
48+
of server-rendered HTML?
49+
</li>
50+
<li>
51+
<strong>SEO and initial load</strong> — Is content present in the first
52+
HTML response (MPA), or does meaningful content only appear after JS downloads
53+
and executes (SPA)?
54+
</li>
55+
</ul>
56+
57+
<h3 id="mpa">Multi-Page Application (MPA)</h3>
58+
<p>
59+
In an MPA, each navigation triggers a full browser request and the
60+
server responds with a complete HTML document. HTML is generated on the
61+
server per request, so the browser always receives ready-to-display
62+
content. JavaScript is optional and typically used only for progressive
63+
enhancement. In-memory state is lost on every navigation. Because
64+
content is present in the initial HTML response, MPAs are naturally
65+
SEO-friendly. The server must be capable of rendering and serving a full
66+
page for every route.
67+
</p>
68+
69+
<h3 id="spa">Single-Page Application (SPA)</h3>
70+
<p>
71+
In an SPA, the browser loads a single HTML shell once and all subsequent
72+
navigation is handled client-side by JavaScript, without full page
73+
reloads. HTML is generated in the browser, typically by a JavaScript
74+
framework rendering components on demand. On initial load the browser
75+
receives a minimal document and must download and execute JS before
76+
content appears. Subsequent navigations fetch only data (e.g. via API
77+
calls), keeping the page transition fast. In-memory state persists
78+
across navigation. Because the initial HTML shell contains little
79+
content, SPAs require extra effort (SSR, prerendering) for good SEO. The
80+
server only needs to serve static assets.
81+
</p>
82+
</section>
83+
84+
<section>
85+
<h2 id="rendering-patterns">Rendering Patterns</h2>
86+
<p>
87+
A rendering pattern describes how and when content is generated and
88+
delivered to the client, typically the browser. The rendering process
89+
can happen on the client or on a server, and at different stages of the
90+
application lifecycle.
91+
</p>
92+
<p>
93+
Each pattern has different tradeoffs in terms of performance, SEO, UX,
94+
resource usage, robustness, and complexity. The choice of rendering
95+
pattern can have a significant impact on the overall experience and
96+
maintainability of the application.
97+
</p>
98+
99+
<h3 id="ssg">Static Site Generation (SSG)</h3>
100+
<p>
101+
All pages are pre-built into static HTML files at build time (ahead of
102+
time) by a build tool or framework. The output is a set of
103+
ready-to-serve files — one per route — that can be delivered directly
104+
from a CDN with no server needed at runtime. Because every response is a
105+
pre-built file, load times are fast and infrastructure is simple. Best
106+
suited for content that doesn't change per request.
107+
</p>
108+
109+
<h3 id="ssr">Server-Side Rendering (SSR)</h3>
110+
<p>
111+
HTML is generated on a server for each incoming request (just in time).
112+
This allows dynamic content and per-request logic such as
113+
authentication, personalization, or A/B testing. Unlike SSG, SSR
114+
requires a running server at runtime.
115+
</p>
116+
<p>
117+
The term SSR is often used together with
118+
<a href="#hydration">hydration</a>. However, classic SSR works without
119+
hydration — the server sends functional HTML that relies on native
120+
browser capabilities (links, forms) rather than a JavaScript framework.
121+
This is the traditional web model where JavaScript is only used for
122+
progressive enhancement, not for rendering core content.
123+
</p>
124+
125+
<h3 id="csr">Client-Side Rendering (CSR)</h3>
126+
<p>
127+
Instead of receiving ready-made HTML from a server, the browser receives
128+
a minimal HTML skeleton and a JavaScript bundle. The JS framework then
129+
fetches data, builds the DOM, and controls all rendering on the client
130+
side.
131+
</p>
132+
<p>
133+
This enables highly dynamic interfaces where the page can update without
134+
full reloads. The tradeoff is a slower initial load — nothing meaningful
135+
appears until the JavaScript has downloaded and executed — and weaker
136+
SEO by default, since the initial HTML response contains little content.
137+
</p>
138+
139+
<h3 id="hydration">Hydration</h3>
140+
<p>Hydration is the process of ...</p>
141+
142+
<h3 id="partial-hydration">Partial Hydration</h3>
143+
<p>Partial Hydration is a technique where ...</p>
144+
145+
<h3 id="progressive-hydration">Progressive Hydration</h3>
146+
<p>Progressive Hydration is a technique where ...</p>
147+
148+
<h3 id="streaming">Streaming</h3>
149+
<p>Streaming is a rendering approach where ...</p>
150+
151+
<h3 id="isr">Incremental Static Regeneration (ISR)</h3>
152+
<p>ISR stands for Incremental Static Regeneration, which ...</p>
153+
154+
<h3 id="ppr">Partial Prerendering (PPR)</h3>
155+
<p>Partial Prerendering is a rendering strategy where ...</p>
156+
157+
<h3 id="islands">Islands Architecture</h3>
158+
<p>Islands Architecture is a pattern where ...</p>
159+
160+
<h3 id="rsc">Server Components (RSC)</h3>
161+
<p>Server Components are components that ...</p>
162+
163+
<h3 id="esr">Edge-Side Rendering (ESR)</h3>
164+
<p>Edge-Side Rendering is an approach where ...</p>
165+
</section>
166+
</main>
167+
168+
<style>
169+
main {
170+
margin: 0 auto;
171+
padding: 40px 16px;
172+
max-width: 900px;
173+
174+
font-family:
175+
'Inter',
176+
-apple-system,
177+
BlinkMacSystemFont,
178+
'Segoe UI',
179+
Roboto,
180+
Oxygen,
181+
Ubuntu,
182+
Cantarell,
183+
'Fira Sans',
184+
'Droid Sans',
185+
'Helvetica Neue',
186+
sans-serif;
187+
min-height: 100vh;
188+
color: var(--ft-text);
189+
background-color: var(--ft-bg);
190+
line-height: 1.5;
191+
}
192+
193+
section {
194+
width: 100%;
195+
max-width: 900px;
196+
}
197+
198+
@media screen and (max-width: 768px) {
199+
main {
200+
padding: 20px 16px;
201+
}
202+
}
203+
204+
.detail-header {
205+
margin-bottom: 2em;
206+
}
207+
208+
.detail-title {
209+
font-size: 32px;
210+
margin: 0 0 0.25em 0;
211+
font-weight: 700;
212+
background: var(--ft-gradient);
213+
-webkit-background-clip: text;
214+
-webkit-text-fill-color: transparent;
215+
background-clip: text;
216+
}
217+
218+
p,
219+
ul {
220+
font-size: 16px;
221+
color: var(--ft-muted);
222+
line-height: 1.6;
223+
margin-bottom: 1em;
224+
max-width: 700px;
225+
}
226+
227+
section {
228+
margin-top: 2em;
229+
}
230+
231+
h1 {
232+
font-size: 32px;
233+
margin-top: 0.25em;
234+
margin-bottom: 0.5em;
235+
font-weight: 700;
236+
background: var(--ft-gradient);
237+
-webkit-background-clip: text;
238+
-webkit-text-fill-color: transparent;
239+
background-clip: text;
240+
}
241+
242+
h2 {
243+
font-size: 20px;
244+
margin-top: 2em;
245+
margin-bottom: 1em;
246+
font-weight: 600;
247+
color: var(--ft-text);
248+
}
249+
250+
h3 {
251+
font-size: 16px;
252+
margin-top: 1.5em;
253+
margin-bottom: 0.75em;
254+
font-weight: 600;
255+
color: var(--ft-text);
256+
}
257+
</style>
258+
</Layout>

0 commit comments

Comments
 (0)