A React app got pulled after 3 days. The plain-HTML rebuild doubled completions

A regulated utility had two failed attempts behind it, including a React app yanked after 72 hours of customer complaints. The fix wasn't a framework. It was a form that works with JavaScript switched off.

In brief

The site faced millions in fines if customer satisfaction slipped below 96%. The rebuild used Astro, server-rendered each wizard step as its own page, and stored progress in the backend — one user finished a form a month after starting it.

A staff engineer in the thread described doing the same migration in reverse: ripping React out of an internal app and discovering he no longer needed a build process at all.

Two failed builds, then a form that survives a dropped connection

Progressive enhancement
Progressive enhancement

The setup is brutal in a way most "we rewrote it" posts aren't. In the original write-up, the author describes a regulated utility monopoly that needed customers to apply for a service. Two earlier attempts had failed — including a React app pulled after just three days because of customer complaints. The stakes were regulatory: if satisfaction dropped below 96%, the company faced "millions of pounds in fines."

The rebuild's principle was that JavaScript should enhance, never gate. Built on Astro, "Javascript existed, in web components, but only to progressively-enhance a website that worked perfectly fine without it." Each step of the form wizard was its own server-rendered page with backend validation, so progress persisted no matter what the browser did — one user "completed a form a month after starting it." The whole client-side validation layer was a web component under 1KB that fell back to the browser's built-in validation if it failed to load. The result: "the number of people completing the form doubled," and analytics couldn't even locate the new arrivals, because the old JS-based tracking had been silently losing them.

"I couldn't come up with a single good reason this app needed React"

The thread filled with engineers who'd run the same experiment on their own codebases. A staff engineer described a migration that ended somewhere he didn't expect:

"I couldn't come up with a single good reason why this app needed React. I rewrote the frontend in straight HTML with a little bit of JavaScript … But you know what I didn't need? A BUILD PROCESS! No npm deps. No vite/rsbuild/etc. It was like I had forgotten we could even DO that." — a staff engineer

Someone who builds this exact category of site for a living added historical depth — the accessibility-first form wizard isn't new, it's rediscovered:

"I built apps like these on GOV.UK over 10 years ago for the Ministry of Justice. We built our own form wizard library that let us validate long forms in steps … It was a very important principle … that everyone should be able to make use of these digital services regardless of whatever users were using to access them." — the founder of Teller, an API for bank accounts

The counter-voice: this isn't a React problem

The dissent worth keeping was a refusal to make it tribal. A high-karma regular pushed back on the framing itself:

"People who built a crappy website using React are just as likely to build a crappy website using Astro, HTML-first approach or any other technology" — entropichorse

And a React user noted you don't even have to leave the ecosystem to get the benefit: "you can render components to HTML and serve that to the user … the browser gets pure HTML with zero JS by default," wrote one engineer who'd done exactly that under similar constraints.

One reader caught the headline's sleight of hand, which the author half-admits:

"I was a little confused by 'doubled our users' since that's more about inbound traffic … I guess it's really shorthand for 'halved form abandonment' which is still pretty great." — tootie

The rule isn't "HTML good, React bad"

The honest takeaway is narrower and more useful than the framework war it triggered. For a form whose users are the general public on whatever device and connection they happen to have, designing for the failure mode — no JS, old browser, flaky network — produced a better happy path too. As one commenter put it, "Designing for failure modes … often leads to better systems even in the happy path." The doubling wasn't magic; it was the people the old build was quietly dropping, finally getting through.

Get breakdowns like this every day

The top Hacker News stories, unpacked — by email, Telegram, or RSS.

Next story · 21 of 22 Read more
🔥Hot Discussion

Anthropic's security model blocks the researchers it was built to help

An IBM X-Force researcher couldn't get Fable to read a blog post — the guardrail flagged it as 'cyber'. The model that's supposed to assist defenders keeps slamming the door on them.

★ 221 · 💬 211 · techcrunch.com · 5 min