Building an HTML-first site doubled our users overnight

Original Article ↗ Hacker News Discussion ↗

An anecdote about a UK utility replacing a fragile JavaScript-heavy form with an Astro-powered, “HTML‑first” site that doubled completed applications has reignited debate over how the web should be built. Many commenters argue that progressive enhancement, standard HTML forms and server-side rendering yield faster, more accessible services—especially for users on low-end devices, poor connections or old browsers—while others note that competent teams can achieve good results with React and SPAs as well. The thread highlights how defaults, tooling ecosystems and developer education often push teams toward overcomplicated front ends, with real costs for usability, accessibility and even basic reach.

HTML-first & progressive enhancement

  • Many see the story as a strong case study for HTML-first, progressively enhanced sites, especially for public services and forms.
  • Classic web patterns (links, forms, redirects, multi-page “wizards”) are praised for:
    • Working with JS off or broken.
    • Giving users built-in browser behaviors (back/forward, validation UI, focus, keyboard access).
    • Reducing invisible failure modes common in SPAs (spinners, silent JSON errors).
  • Some note this is essentially a rediscovery of “progressive enhancement” and what frameworks like Rails/Django have long encouraged.

React, SPAs, and performance

  • A recurring theme is frustration with heavy React/SPA stacks, build steps, and megabytes of JS for basic forms or mostly-static content.
  • Several argue that while you can build good UX with React, it’s easier to build bad, fragile, inaccessible, or bloated apps:
    • Defaults skew toward client-side rendering and custom widgets instead of semantic HTML.
    • Many developers don’t know how to build working forms without JS.
  • Others push back: the real issue is design and developer skill, not the framework itself; you can also ship HTML-only React or slow server-rendered sites.

Astro, HTMX, Go and other stacks

  • Astro is repeatedly praised for defaulting to static HTML and “opt‑in” islands of JS, unlike React/Next’s “opt‑out” tendency.
  • HTMX + Go + SQLite is cited as a “boring but effective” stack for many apps, with minimal JS and easy deployment.
  • Some discuss Hotwire, server-driven mobile approaches, static site generators (Jekyll), and simple SSR as viable alternatives.

Accessibility, devices, and user empathy

  • Commenters highlight real users on low-end phones, old browsers, consoles, or poor connections; these users are often invisible to JS-based analytics.
  • There’s debate over how many users actually lack JS or modern TLS:
    • One side: even if it’s ~1%, they’re often the most vulnerable and services (especially gov/utility) should accommodate them.
    • Others argue HTTPS‑only and JS‑heavy practices are now the norm, sometimes driven by browser and platform policies.
  • Age and digital literacy are discussed: many non-technical users (of all ages) lack mental models of complex UIs, so simple, robust flows matter.

Metrics, trade-offs, and culture

  • Several note the “doubled users” result is really about higher form completion / lower abandonment, not traffic.
  • Some emphasize trade-offs:
    • HTML-first can mean more bespoke UI work and fewer ready-made component libraries.
    • Teams and hiring pipelines are optimized for React; deviating can feel risky or “more work.”
  • There’s broader criticism of industry incentives: fashion-driven tooling, under-emphasis on fundamentals, and weak empathy for slow devices and disadvantaged users.