Static vs Dynamic Pages: Which Fits What?

_Locale: en-US · Lesson: WEBF-003 · Public order: 30_

Outcome and working artifact

This lesson produces a Static/Dynamic Decision Ledger v1: a decision artifact that separates observations, assumptions, limits, and required evidence. The goal is a transferable model, not memorized tool names.

For a bounded page requirement, identify what can remain pre-produced, what must vary, where variation can occur, and what evidence would justify the decision.

Boundary model

Static and dynamic describe where and when a representation varies; they do not map cleanly to 'without JavaScript' and 'with JavaScript', or to 'without a database' and 'with a database'. A page can be pre-produced and still run rich client code. A request-time response can be dynamic even if it reads no database. The decision starts with the source of variation.

Keep three labels throughout the work: observed, bounded inference, and needs verification. When evidence is unavailable, record unknown. A product name or a passing happy path is not a substitute for evidence.

1. Describe the response, not the brand

Ask whether the delivered representation was already available or was generated for this request. Framework names are implementation clues, not the classification itself.

2. Separate server generation from client updates

Pre-generated HTML can contain JavaScript that changes theme, filters a list, or fetches later data. That client-side change does not retroactively make the original server response request-generated.

3. A database is optional

Request-time output can depend on headers, time, a computation, an upstream service, or configuration. Conversely, a build process can read a database and emit fixed files.

4. Classify parts, not slogans

A page can combine a pre-produced shell, a request-time status fragment, and client-side personalization. One global label often hides the architecture that matters.

5. Tie the choice to change frequency and evidence

Record who changes the information, how quickly it must appear, whether it is user-specific, what failure behavior is acceptable, and how cache invalidation is controlled.

Five-step method

1. Split the page into independently varying regions.
2. For each region, identify the variation source: content author, deployment, request context, user state, or live upstream data.
3. Choose the production moment: build time, request time, or browser runtime.
4. Record cache scope, invalidation trigger, failure fallback, privacy boundary, and accessibility impact.
5. Use a mixed classification when the architecture is mixed; do not force one label onto every region.

Worked case

A documentation page ships pre-built HTML. A theme preference is read in the browser and changes classes without asking the server. A small service-status badge is fetched at request time from an endpoint. The defensible ledger calls the document body pre-produced, the theme client-dynamic, and the badge request-dependent. It then records separate cache and failure rules. Calling the entire page simply 'dynamic' would lose the decision boundaries.

Decision and evidence matrix

Failure probes and repair

• Static pages cannot include JavaScript.
• Dynamic pages require a database.
• Static is always faster or more secure.
• This split-curriculum page does not claim ownership of the complete WEB-000 Web Mental Model.

For each statement, narrow the claim, create a counterexample, and name the observation that could confirm or reject it.

Transfer challenge

Change the scenario so that one assumption in the worked case no longer holds. Rebuild the Static/Dynamic Decision Ledger v1 without copying the earlier decision, then explain what changed in the input and what stayed stable in the decision rule.

What this does not prove

This lesson does not claim certification, production guarantees, or coverage of every implementation. Its conclusion is valid only within the scenario boundary, dated sources, and recorded observations.

Self-check

• [ ] Did I separate responsibilities from framework or tool names?
• [ ] Did I state at least one failure probe and its predicted observable?
• [ ] Are fact, inference, and design choice visibly separated?
• [ ] Did I record non-claims and missing evidence?
• [ ] Did I complete transfer in a changed context without a prepared answer?

Sources and freshness boundary

Sources were reviewed for the frozen Bible as of 2026-09-19. A review_due date triggers a versioned requalification; it does not authorize silent in-place edits.

• S-MDN-CS — Static and dynamic server response model. (https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Client-Server_overview; review: 2026-12-31)
• S-MDN-JS — Client-side and server-side dynamic behavior distinction. (https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Scripting/What_is_JavaScript; review: 2026-12-31)