Building a robust frontend using progressive enhancement

Original Article ↗ Hacker News Discussion ↗

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.