Original title: How building an HTML-first site doubled our users overnight
Article
An engineer replaced a costly failed SPA rewrite for a UK utility company’s regulated customer-application flow with an Astro-based HTML-first implementation that prioritized compatibility, accessibility, and resilience. The earlier React version failed from heavy client-side state, poor user experience, and storing files plus form data in localStorage, which is unsuitable for larger uploads and unstable sessions. The new build used a multi-page form wizard where each step posts to the backend and advances via redirect, so users could continue even with weak networks, old browsers, or JavaScript disabled. Backend sessions preserved progress at each step, preventing form data loss over long gaps, and enabling successful completion after prolonged interruption. The team implemented a lightweight custom validation component to enhance native HTML validation and ARIA messaging, while always falling back to browser or server validation when enhanced behavior failed. Requirements were explicit: universal reach, graceful failure, WCAG AA conformance, and JavaScript used only as progressive enhancement. This architecture was presented as the right fit for a large form workflow where users may be on very old devices and where reliability matters more than real-time interaction. After launch, form completions were reported to double, and analytics captured previously unseen sustained usage once JavaScript failures stopped bouncing users. The post’s broader claim is that public services should optimize for constrained environments, including low-spec devices and degraded network conditions, because robust foundations scale farther than trendy client-heavy patterns for this use case.
Readers largely agreed on reducing user friction and network cost, while pushing back on the “HTML-first” label as potentially overhyped terminology rather than a guaranteed solution. Several commenters echoed prior public-sector experience where multi-step server-driven forms improved accessibility and universal usability, especially for citizens on legacy devices. Others shared stack choices like Jekyll, HTMX, Go, Ruby-era patterns, and plain HTML plus minimal JavaScript, arguing that build tooling and framework overhead are often avoidable. A few comments nuanced the debate by noting SPA frameworks can still be appropriate, especially when React renders to HTML and ships without mandatory JavaScript, and one corrected that the renaissance pattern is often associated with Next.js as much as Remix. Several remarks reframed the headline claim, suggesting the real metric may be lower form abandonment rather than raw traffic growth. Additional discussion linked the case to broader infrastructure and performance strategy, including CDN layering and mobile app limitations around storage and update friction. Some commenters appreciated the accessibility argument and broader anti-hype sentiment, while one explicitly objected to implied blame tied to contract geography. The overall thread recognized fundamentals—clarity, graceful degradation, and respect for constrained users—as central regardless of framework choice.