On Monday, a developer named Mohamad Kohn posted a blog entry titled “Building an HTML-first site doubled our users overnight.” By Tuesday it had 868 points on Hacker News and a comment thread spilling past 400 posts. The gist: Kohn’s form-building startup, FormSling, was chugging along with a React frontend until he rewrote the product to work as plain HTML forms — server-rendered, progressively enhanced, functional on a PlayStation Portable browser — and watched signups jump 2x, essentially overnight.

Predictably, the replies sorted into two camps. Camp one: vindicated minimalists who’ve been saying “just write HTML” since 2015. Camp two: defensive engineers explaining that React scales and you wouldn’t understand.

Both camps are missing the actual story.

The Users Who Were Never in Your Funnel

The detail buried in Kohn’s post — the one that should make every product manager in San Francisco pause — is the list of browsers and devices his new architecture suddenly supported. Old phones. Low-end hardware. Spotty connections where a 300KB JavaScript bundle means a 12-second spinner and then nothing. A PlayStation Portable browser, for crying out loud.

These aren’t edge cases. They’re people. And for the better part of a decade, the dominant frontend paradigm in web development treated them as rounding error.

When you build a single-page application with a 2MB initial load, you’re not just making technical choices. You’re drawing a line around who can use your product. That line correlates neatly with income, geography, device age, and connection quality. A midrange Android phone in rural India will choke on the average SaaS landing page. A refurbished iPhone 8 — still perfectly functional hardware — can’t meaningfully use half the web apps shipped in the last three years.

Kohn didn’t just make his site faster. He made it legible to an entire cohort of users who’d been silently excluded.

The Bundle as a Class Barrier

Here is the argument nobody in the thread is making: modern web development has become a class filter, and we’ve been pretending it’s a quality filter.

“Performance budgets” are a thing at Google and the Financial Times. They’re not a thing at the average venture-funded startup, where the engineering team uses MacBook Pros on corporate Wi-Fi and tests on whatever Chrome version shipped last Tuesday. The median web page now weighs over 2.5MB, per HTTP Archive data tracked through early 2026. For someone on a capped data plan in Indonesia, loading a single page of your app might cost real money — money they’d rather not spend to watch a skeleton screen animate into a form.

This isn’t a call for everyone to abandon frameworks. It’s an observation that the industry has conflated developer experience with user experience, and the users who lost out were the ones least able to complain. They didn’t file GitHub issues. They just left.

A web that works without JavaScript is a web that works for people who can’t afford the latest hardware, don’t live in fiber-optic neighborhoods, and didn’t learn to code. That’s not a niche aesthetic preference. It’s a structural question about who gets to participate.

What the Doubling Actually Proves

Kohn’s user numbers doubling isn’t evidence that HTML is “better” than React. It’s evidence that there was a large, underserved population waiting on the other side of a compatibility gate they couldn’t open. The gate wasn’t malicious. It was just invisible to the people who built it.

“I always assumed our target user had a decent laptop and Chrome,” one engineer at a mid-stage SaaS company told me in a Slack DM after the HN thread blew up. “We never checked what happened on a five-year-old phone. I don’t think anyone on the team owns a five-year-old phone.”

That’s the quiet part, said out loud. The development class builds for itself, tests on its own hardware, and wonders why the addressable market feels artificially capped.

The FormSling story isn’t a parable about the evils of JavaScript frameworks. It’s a parable about who gets to be a user — and who the industry decided doesn’t count.

The Inconvenient Question

The uncomfortable question the HN thread mostly dodged: How many other SaaS products have the same untapped user base sitting behind a bundle wall? How many signup flows, checkout pages, and onboarding wizards would double their conversion if they simply worked on the devices people actually own?

This isn’t the argument the minimalist crowd wants to make. They want to talk about elegance and simplicity and the virtue of hand-crafted markup. And it’s not the argument the React defenders want to engage with — they’d rather litigate whether server components solve this or whether the comparison is fair.

But the number is right there in the blog post. Doubled. Not optimized 5%. Not a marginal conversion lift. Doubled. That magnitude suggests the previous version wasn’t just suboptimal — it was actively turning people away.

The industry’s response to Kohn’s post has been a mixture of nostalgia and defensiveness. Neither is useful. The useful response would be to check your own analytics, filter by device and connection type, and ask how many people bounced before your app even finished loading. The answer might be uncomfortable. It might also be the fastest growth lever you’re not pulling.

Sources