The author documents his own rebuild: replacing a React SPA with server-rendered HTML plus minimal vanilla JS, which collapsed bundle weight and LCP. He reports daily active users approximately doubled within the first week, framing it as direct evidence that the SPA architecture was actively suppressing engagement.
The editorial argues this is the fourth comparable case study to top HN in 18 months — citing Inkstone's similar lift, GitHub's primer team walking back hydration-heavy components, and Basecamp's two-year Hotwire evangelism. The receipts have moved from anecdotal to a repeatable, documented pattern across independent teams.
The editorial pushes back on the simplistic 'JS bad, HTML good' framing, arguing the actual failure mode is more specific: SPAs ship an HTML shell that looks ready but blocks clicks behind a JS bundle that must download, parse, execute, and reconcile. On flaky mobile connections this creates a 2-6 second gap where users tap dead pixels — and that's what drives them away, not JavaScript as a category.
Mohkohn — a UK indie dev running a content site — published a postmortem this week with a title that's hard to ignore: "Building an HTML-first site doubled our users overnight." The HN thread cleared 1,178 points in a day, which is the kind of number you only see when a story hits a nerve the community already had.
The rebuild itself is unspectacular by design. He pulled out a React SPA, replaced it with server-rendered HTML, kept a sprinkle of vanilla JS for the interactive bits, and shipped. No framework migration, no edge-runtime gymnastics, no islands architecture branding. Total bundle weight dropped from a few hundred kilobytes to roughly nothing. LCP collapsed. And then — per his own analytics — daily active users approximately doubled within the first week.
What makes this notable isn't the result; it's that it's the fourth time in 18 months a developer has published essentially the same case study and topped HN with it. Inkstone reported a similar lift after dropping their SPA. GitHub's primer team has been publicly walking back hydration-heavy components. Basecamp has spent two years evangelizing Hotwire on the back of comparable internal numbers. The receipts are no longer anecdotal.
The instinct on seeing one of these posts is to file it under "JS bad, HTML good" and move on. That framing is wrong and it's why the lesson keeps failing to stick. The actual mechanism is more specific and more interesting.
The failure mode in every documented case is the same: a hydration-heavy SPA ships an HTML shell that looks correct, then blocks meaningful interaction behind a JS bundle that has to download, parse, execute, and reconcile with the DOM before anything is clickable. On a fast laptop with warm cache, this gap is invisible. On a cold load over a flaky mobile connection — which is what most of your real users are doing — the gap is 2 to 6 seconds of a page that looks ready but isn't. Users tap, nothing happens, they leave. Your funnel analytics call this "high bounce rate." Your RUM dashboard calls it a TTI regression. Both are describing the same thing: a structural mismatch between what your page looks like and what it can do, and users learn to distrust the gap.
There's a second-order effect that the case studies undercount. Search crawlers, social preview bots, AI ingest pipelines, and increasingly the LLM-powered "answer" surfaces (Google's AI Overviews, Perplexity, ChatGPT browse) all render with limited or no JS execution budget. An SPA that renders fine in your browser can render as an empty `
The community reaction in the HN thread is worth reading. The top comment isn't celebrating — it's tired. The sentiment, paraphrased across hundreds of replies: we knew this in 2014, we've been saying it since hydration shipped, we're glad you ran the experiment but please stop making us argue about it. The dissent worth taking seriously isn't "SPAs are fine." It's the narrower point that this analysis ignores: apps with genuine client state — collaborative editors, design tools, dashboards with cross-filtering — get nothing from a server-rendered rewrite and lose real functionality. That's correct. The HTML-first lesson is about *documents*, not *applications*, and the two industries have been smeared together by frameworks that pretend they're the same problem.
The practitioner question isn't "should I rewrite to HTML-first." It's "do I have the symptom these rewrites are curing." There's a quick diagnostic: pull up your real-user monitoring and look at the gap between TTFB and LCP, then between LCP and TTI. If TTFB-to-LCP is under 500ms but LCP-to-TTI is over 1.5 seconds, you have the exact disease every one of these case studies is treating, and your funnel is paying for it whether you've noticed or not.
The migration paths are now well-trodden enough to pick by stack. If you're on Next.js, the App Router with server components is the in-place fix — most of the bundle weight is hydration of components that don't need to be interactive. If you're on Rails, Hotwire is doing this already and the upgrade is mostly deletion. If you're on a Vue/Nuxt setup, Nuxt 3's server-only components map cleanly. And if you're running a hand-rolled React SPA shipping a 400KB bundle to render a marketing site, the honest answer is that you don't need a framework migration — you need to delete React from the pages that don't need it, which is almost all of them.
The thing not to do is treat this as a binary. The wins in every documented case come from moving the *document-shaped* parts of the product to server rendering while keeping the *application-shaped* parts as client-side islands. The frameworks that have absorbed this — Astro, Qwik, Fresh, the new Next.js — are not religious about it. The teams losing the most are the ones still defending a uniform SPA architecture for sites that are 90% read-only content.
The meta-story here is that the industry's framework-default assumption is finally breaking down in public, one postmortem at a time. None of these case studies are converting anyone who wasn't already half-convinced — but they're reshaping what the senior-engineer reflex looks like when a new project starts. The next year of "what stack should we use" conversations will, increasingly, start with the question of how much of the product is documents versus how much is application, and the answer will determine the framework rather than the other way around. The HTML-first crowd isn't winning the argument because they're right. They're winning because the receipts are now load-bearing.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.