Building a robust frontend using progressive enhancement

Original Article ↗ Hacker News Discussion ↗

Progressive enhancement and HTML‑first design are held up as a way to make government and public‑facing services faster, more robust, and accessible to all users, including those with older devices, assistive tech, or disabled JavaScript. Many commenters argue that today’s heavy use of SPAs and JavaScript frameworks often adds unnecessary complexity, breaks built‑in browser behaviors, and shifts costs and risks to users, despite modest UX gains for most “forms and tables” sites. A minority note that modern frameworks can be made accessible and performant, but concede this demands more care and typically only pays off for truly complex, app‑like interfaces.

Overall sentiment toward progressive enhancement

  • Many commenters strongly endorse the guidance and wish more of the web followed it.
  • Several report personal frustration that sites fail completely without JavaScript for content that could be plain HTML.
  • Gov.uk is praised for clear writing, consistent design, and for prioritizing accessibility and simplicity.

SPAs vs server-rendered / multi-page apps

  • Common view: most apps that are basically “forms and tables” should be HTML + CSS with minimal JS; SPAs often add huge complexity for marginal UX gain.
  • Others argue SPAs are not inherently inaccessible or broken; careful implementations can preserve history, focus, back/forward, and assistive tech.
  • Several say SPAs make sense when the app is offline-capable or “desktop-like” (e.g., Google Docs, graphics tools).

Accessibility, performance, and reliability

  • Progressive enhancement and plain HTML “get a lot for free”: navigation, back button, refresh, error recovery, assistive tech.
  • SPAs must reimplement these behaviors, and many do it poorly, leading to broken keyboard navigation, links, and form behavior.
  • JS bloat, heavy dependencies, and client-side frameworks are blamed for slow load times, high CPU use, and poor experience on low-end devices.

Developer experience, complexity, and incentives

  • Recurrent theme: modern frontend stacks are vastly more complex than necessary; teams spend time on tooling, builds, and dependencies rather than user needs.
  • Some see frontend as a “jobs program” or CV-padding: complex stacks are chosen to stay trendy, appear “serious,” and help promotions.
  • Others counter that large, evolving UIs have inherent complexity; component frameworks help with modularity, styling, testing, and state.

Government context vs private sector

  • Government services must work for nearly everyone, including old devices, JS-disabled setups, and assistive technologies.
  • Businesses often accept partial accessibility and chase flashy SPAs, especially for demos and internal optics.

Frameworks and alternatives

  • Mixed views on React: seen as powerful but over-complex with hooks.
  • Some prefer Svelte, HTMX, Alpine, Livewire, Mithril, or classic SSR (Rails, Django) as simpler, more standards-aligned approaches.
  • Desire expressed for “component frameworks without SPA routing/state” and for HTMX-like capabilities baked into browsers.

Critiques of the guidance

  • Some say the article overstates SPA drawbacks or feels stuck in early-2000s thinking, noting modern SSR/hydration and accessible SPAs.
  • Others think the language (“should consider”) is softer than the intent, especially in a governmental context.