The author argues that every script tag was 'paying rent' that almost none earned, and that rebuilding as static HTML with light progressive enhancement doubled daily active users overnight with no other changes. He frames the gain not as a framework win but as recovering users on old Androids, locked-down work laptops, and flaky connections who could never load the SPA version.
The editorial concedes the site is small and the absolute numbers aren't enterprise-scale, but argues the pattern is what's significant: time-to-interactive collapsing from seconds to near-zero, bounce rate falling, and pages-per-session climbing. That signature points to a latent audience being unblocked rather than a marketing or content effect.
The editorial frames server-rendered HTML as having been rebranded as 'legacy' only to be reintroduced under new names — server components, islands, resumability, partial hydration — each adding abstraction to recover what plain HTML always had. The HTML-first rebuild is positioned as evidence that the original document model was never the problem.
The author explicitly didn't swap React for Svelte or Next for Astro — he swapped 'JavaScript by default' for 'HTML by default' and measured the result. His point isn't that one framework beats another but that the baseline decision of whether to ship a runtime at all is the variable most teams never actually test.
A solo developer running a small personal site rebuilt it from a JavaScript SPA into plain HTML pages with light progressive enhancement. The post on mohkohn.co.uk — which hit Hacker News at 892 points — claims daily active users roughly doubled the day the new version went live. No marketing push, no new content, no SEO blitz. Same URLs, same articles, same author. The only variable was the stack.
The old version was the default modern setup: a JavaScript framework, client-side routing, a hydration step on every page load, and a bundle that had to download and execute before anything interactive appeared. The new version is HTML rendered at build time, CSS in a single small file, and a sprinkle of vanilla JS only where interactivity is actually needed — search, a theme toggle, a couple of widgets. The author's framing is blunt: every script tag was paying rent, and almost none of them earned it.
The numbers in the post are not enterprise-scale, and the author admits that. But the *shape* of the change matters more than the magnitude. Time-to-first-byte stayed roughly the same. Time-to-interactive dropped from "a couple of seconds" to "basically zero." Bounce rate fell. Pages-per-session climbed. The browsers that used to choke — old Androids, locked-down work laptops, anything on a flaky train connection — suddenly worked.
This story keeps trending because it's not a framework war post. It's a measurement post. The author didn't switch from React to Svelte or from Next.js to Astro — he switched from "shipped JavaScript by default" to "shipped HTML by default," and the audience that was always there but couldn't load the site showed up.
The industry spent a decade convincing itself that the document model was a legacy compromise. Server-rendered HTML got rebranded as "the old way," then quietly reintroduced as "server components," "islands," "resumability," and "partial hydration" — each one a new abstraction on top of the abstraction we built to escape HTML. Every layer has a runtime cost. Every runtime cost gets paid on the user's device, not yours. Chrome's own Core Web Vitals data has been showing this for years: the median real-world LCP for SPA-architecture sites is roughly 2x worse than for server-rendered sites in the same category.
The Hacker News thread is unusually unanimous for HN. The top comments aren't "but what about state management" — they're "yes, we did the same migration at $COMPANY and traffic went up." A senior engineer at a mid-size SaaS posted that their conversion funnel improved 18% after moving the marketing site off Next.js to a static generator. A Shopify dev pointed out that the theme stores with the lowest JS budgets convert the best, every quarter, with no exceptions. The pattern is so consistent that "reduce JavaScript" is now more reliable advice for a content site than any specific framework recommendation.
There's a generational angle too. Engineers who learned web development in the React era treat HTML as an output format — something a framework emits. The post is a reminder that HTML is a *protocol*, the same way HTTP is a protocol. Browsers are aggressively optimized for it. Search engines are optimized for it. Screen readers are optimized for it. Caches, CDNs, and proxies are optimized for it. When you ship a 400KB bundle that renders a `
The honest read: most content sites don't need a SPA, and a lot of product sites don't either. If your TTFB beats your hydration time by 3+ seconds, you're paying SPA tax for content that never needed JavaScript in the first place. The test is not philosophical. Open your site in Chrome DevTools, throttle to Fast 3G, and watch what happens. If the screen is blank for two seconds while a bundle parses, that's churn you can measure.
This doesn't mean delete React. It means audit which pages actually benefit from it. Marketing pages, blog posts, docs, pricing, landing pages, status pages, changelog, about — none of these need a virtual DOM. They need HTML, CSS, and maybe a 5KB script for a mobile menu. The dashboard, the editor, the real-time collaboration view — those earn their JavaScript. Drawing the line clearly is more valuable than picking a framework.
The tooling for this hybrid is mature now. Astro, 11ty, Hugo, and plain build scripts all do static HTML well. Next.js and Remix have static export modes that work if you actually use them. Even a Makefile and a templating language is a legitimate choice. The migration the HN post describes took a weekend, not a quarter. The biggest blocker is cultural — convincing a team that "we use Next" doesn't mean every page has to be a React component.
The next 18 months will likely see more of these posts, not fewer. Core Web Vitals are now a Google ranking factor, ad networks penalize slow pages, and the cost of LLM-assisted rewrites has collapsed — meaning the activation energy to migrate off a heavy SPA is the lowest it has ever been. Expect a wave of "we deleted React from our marketing site and traffic went up" posts, followed by the inevitable backlash, followed by a quiet consensus that the right answer was always "use the lightest tool that solves the problem." The developer who doubled his users overnight didn't discover anything new. He just stopped ignoring what the browser was telling him.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.