HTML in the Modern Web

The tools change; the artifact does not. Whatever the stack, somebody authors the markup that users receive — and that person decides the landmarks, the alt text, the labels, and the loading strategy. This chapter is the bridge from "HTML as a subject" to "HTML as a professional skill".

Where HTML comes from

The framework pipeline

Components, templates, and JSX are all build-time representations of markup. The compiler emits render functions; the render functions emit DOM. Two stages of translation — and semantics that survive both stages are the only semantics that matter:

Figure 1 — Everything compiles down to the DOM the user gets.

SSR and SSG

Server-side rendering generates HTML per request; static-site generation generates it per build. Both ship complete documents that render before any JavaScript — which is why they dominate content-heavy sites. The difference is freshness versus cacheability, decided per page:

<!-- what SSR/SSG ship: a complete document, JS optional -->
<!DOCTYPE html>
<html lang="en">
  <head><title>Pre-rendered at build or request time</title></head>
  <body><main><h1>Readable without JavaScript</h1></main></body>
</html>

CSR: the client-rendered trade-off

Client-side rendering ships an empty shell plus a script that builds the DOM in the browser. It trades first-paint speed and crawlability for app-like transitions. Crawlers have improved, but social-card generators and low-end devices still punish empty shells — which is why the industry drifted back to server rendering.

Hydration

The two-phase page

Hydrated pages arrive as complete HTML (paint immediately), then JavaScript re-renders them in memory and attaches event listeners — the page "wakes up". Before hydration, links work but buttons do not; the gap is the UX cost:

Figure 2 — Paint now, interact after hydration.

Hydration mismatches

When server HTML and client render disagree — a different date, a browser-specific branch — the framework warns or re-renders. Nondeterministic markup (timestamps, random ids, locale formats) is the usual culprit; generate it identically on both sides.

Islands and resumability

Newer architectures shrink the hydration cost: islands hydrate only the interactive components; resumability (Qwik) skips re-rendering entirely by serializing state into the HTML. The trend is a vindication of HTML-first design — the closer your framework stays to the document, the less work it redoes.

Framework output quality

Audit the output, not the source

A component can be beautifully written and emit inaccessible markup — a <div onClick> is a div-button whatever the framework calls it. Judge quality in the browser: view-source, the a11y pane, and the validator on the rendered document.

The semantics that survive

Landmarks, headings, alt text, labels, and focus behavior all pass through the compiler — they are data, not syntax. This is why chapters 3–11 are not "static site" knowledge; they are the durable half of every framework codebase.

Web components in frameworks

Custom elements work inside every major framework — the platform's own widget boundary. Design systems increasingly ship web components precisely because they outlive framework churn (chapter 12).

Choosing a rendering strategy

The decision factors

Content freshness (SSG for build-time-known, SSR for per-request), interactivity depth (islands for mostly-static pages, CSR for app shells), and deployment constraints (static hosting needs SSG). Most real sites are hybrids — document per route.

The HTML-first stance

Whatever the tooling, keep the document meaningful without JavaScript: semantics first, enhancement second. Sites built this way survive framework migrations — the HTML is the contract that outlives every tool.

Where to go next

You have the full markup skill set: structure, text, media, tables, forms, semantics, metadata, APIs, delivery. Continue with the CSS roadmap to style it, the JavaScript roadmap to behave it — and return to this track whenever a rendered page surprises you: it is usually the markup.

Common mistakes

Framework-first thinking

Reaching for a component library before asking "what document does this produce" inverts the dependency. The document model is the part users experience; frameworks serve it.

Ignoring the received page

Debugging only component source misses the emitted HTML — where parser repairs, hydration mismatches, and lost semantics actually live. Always verify in the browser.

One strategy for every route

Forcing an entire site into CSR "because the team knows React" (or SSG "because it's fast") mis-serves pages with opposite needs. Mixed rendering is the norm; choose per route.

Practice

Exercises

1. view-source: five framework sites; identify which are SSR, SSG, or CSR from the HTML alone.
2. Build the same small page as a static file and as a component; diff the emitted HTML against your static version.
3. Introduce a hydration mismatch deliberately (a timestamp in a component) and read the warning.
4. Convert one page to an island architecture (e.g. Astro) and compare the shipped JavaScript.

Demo lab

The Lab Examples and Study Projects pages close the track — every demo there is hand-written HTML, the same artifact every framework is measured against.