Progressive Enhancement Strategy

Progressive enhancement creates resilient interfaces — core functionality should work before enhancement.

01 — Purpose

Resilient by default

Progressive enhancement creates resilient interfaces — core functionality should work before enhancement.

Networks fail. JavaScript errors. Extensions block scripts. Progressive enhancement ships a working baseline — semantic HTML, server-rendered content, native forms — then layers interactivity for capable environments.

See semantic HTML and JS module architecture.

02 — Principles

Enhancement improves — it does not invent

Enhancement should improve functionality — not invent it entirely.

  • semantic HTML first — real links, buttons, forms, headings
  • layered enhancement — CSS, then unobtrusive JS, then richer client behaviour
  • resilient forms — submit and validate server-side; enhance client-side
  • accessible defaults — keyboard and AT work before JS runs

03 — Practice

Good progressive enhancement

Core paths work without JavaScript; enhancement adds speed and polish.

  • server-render or statically generate meaningful HTML — see static vs SSR vs CSR
  • hydrate only interactive islands — see islands architecture
  • use progressive hydration for non-critical widgets — see progressive hydration
  • enhance forms with validation and async UX — keep native submit as fallback
  • test with JavaScript disabled on critical journeys — checkout, sign-in, search

04 — Avoid

Fragile JS-only interfaces

When JS is required for basic tasks, resilience and accessibility suffer.

  • JS-only interfaces — blank shell until bundle loads
  • dependency-heavy rendering — entire app requires React/Vue to read a paragraph
  • fragile interaction assumptions — div buttons, custom routing with no href fallback
  • client-only data fetching for public content — SEO and no-JS users lose access
  • skipping server validation — client-only checks that fail open

05 — Close

Baseline first, enhance second

If the page fails with JS off, the architecture is wrong for the content.

Define critical paths that must work without script. Enhance them — do not replace them. This site follows that model: static content, a button-controlled mobile menu with links in nav, and targeted client scripts for nav polish and syntax highlighting. Do not use details / summary for the primary site navigation — it breaks desktop layout.

See hydration costs, dependency management, and JavaScript standard.