The Case for HTML-First: How Progressive Enhancement Doubled Our User Base

A developer replaced a broken, React-based utility form with an HTML-first version that prioritized progressive enhancement and backend data persistence. This shift allowed the site to function on old browsers and poor connections, resulting in a 100% increase in successful user completions. The author concludes that building for maximum compatibility is a professional necessity for essential public services.

Key Points

• Heavy client-side frameworks can exclude users on older hardware or unstable networks, leading to significant data and user loss.
• Progressive enhancement allows a site to remain fully functional without JavaScript while providing a better experience when it is available.
• Storing form progress on the backend at every step prevents data loss and allows users to complete tasks over long periods.
• Native browser features like HTML validation are often more robust and accessible than complex JavaScript library imitations.
• Public and utility services have a professional and ethical obligation to meet high accessibility standards (WCAG) and support all possible devices.

Sentiment

The overall sentiment is strongly favorable toward the article's thesis. Hacker News largely agrees that HTML-first progressive enhancement is the right baseline for essential forms and service workflows, while treating modern frameworks as useful tools that are often overapplied or shipped with harmful defaults. The disagreement is mostly pragmatic rather than dismissive: commenters debate when richer client frameworks are justified, how much extra work HTML-first requires, and whether organizational incentives are more responsible than technology choices.

In Agreement

• Progressive enhancement is the right default for utility, government, and other essential services because the core workflow must survive old devices, weak networks, failed scripts, assistive technologies, and browser variation.
• JavaScript-heavy analytics can hide excluded users, so improved completion after an HTML-first rebuild may reveal people who were previously invisible rather than merely optimize an already measured funnel.
• Modern frontend defaults often make it too easy to replace native controls with fragile approximations, losing keyboard behavior, real links, form semantics, browser validation, and graceful failure modes.
• Many developers now know framework patterns better than basic web primitives, which makes ordinary forms, redirects, server-rendered pages, and semantic HTML feel unfamiliar despite being simpler for many service workflows.
• Server-rendered and HTML-centered stacks such as Astro, Hotwire, HTMX, Rails, Django, Laravel, and similar approaches can deliver fast, maintainable experiences while still allowing selective interactivity.
• Public-sector examples such as GOV.UK show that utilitarian, accessible, form-focused design can be technically modest while still serving users better than polished but fragile interfaces.
• Designing for failure modes often improves the happy path too, because smaller pages, less client state, and clearer server contracts tend to produce faster and more reliable systems.

Opposed

• HTML-first development can require more custom work when teams need rich UI components, polished interactions, or reusable ecosystem pieces that are readily available in modern JavaScript frameworks.
• React and SPAs are not inherently slow or inaccessible; skilled teams can server-render React, use proper semantics, and build robust applications if they choose the right architecture and test carefully.
• Some applications genuinely need complex client-side interactivity, and using plain forms or full page reloads everywhere can recreate old problems that component frameworks were designed to solve.
• The practical cost of hiring, onboarding, and maintaining systems matters; if the labor market mostly knows a framework stack, organizations may choose it even when a simpler stack would be technically sufficient.
• A few commenters question how many people actually lack JavaScript-capable devices, arguing that modern TLS and mobile network requirements already exclude very old clients.
• One skeptical branch suggests that simpler standard forms may also make automation easier, though that concern was pushed back against in the context of real utility application completions.