HN Debrief

Building an HTML-first site doubled our users overnight

  • Programming
  • Web Development
  • Accessibility
  • Developer Tools
  • Public Services

The post is a case study from a contractor who rebuilt a UK utility company’s application flow around plain HTML forms, server-side state, and progressive enhancement instead of a JavaScript-heavy front end. The target users included people on bad connections, low-end devices, and even obsolete browsers. The claim was simple: by leaning on built-in browser behavior like forms, redirects, validation, and page navigation, the team shipped a site that loaded reliably and completed applications at roughly twice the previous rate. A key point in the post was that JavaScript-based analytics never counted many of the people who were failing before the site rendered, so the gains showed up as “new” users when they were really previously excluded ones.

For forms, public services, and anything aimed at broad device coverage, treat plain HTML and server-rendered flows as the default and justify every layer of client-side complexity. If you do keep a JavaScript-heavy stack, test it on cheap Android hardware and slow networks, because your analytics may be hiding the users who fail before the app even boots.

Discussion mood

Strongly positive toward the article’s HTML-first and progressive-enhancement approach, mixed with frustration at JavaScript-heavy web development culture. The mood was driven by years of bad experiences with slow, brittle SPA sites, especially in public services, but tempered by a recurring view that the real issue is poor design choices, team incentives, and misuse of React rather than React alone.

Key insights

  1. 01

    Framework-first training distorts web fundamentals

    Many developers now learn React, build tools, and component libraries before they ever learn the browser request-response model in a concrete way. That flips the mental stack upside down. Plain forms, server rendering, and native validation then look like obscure special cases instead of the baseline the web was built on. The result is not just bloat. It is teams that genuinely experience the simpler path as harder because they lack the underlying model of HTTP, forms, and where code runs.

    If you hire for web work, probe for understanding of HTTP, forms, browser behavior, and progressive enhancement, not just framework fluency. If you run a team, make those fundamentals part of onboarding or you will keep paying a tax in architecture and maintenance.

      Attribution:
    • chao- #1
    • theflyinghorse #1
    • bachmeier #1
    • yesco #1
  2. 02

    HTML-first puts teams in the pit of success

    The strongest argument for the article was not that HTML is always faster to write. It was that standard web building blocks come with good defaults that are painful to lose. Links deep-link. Forms submit. The browser exposes progress, back navigation, keyboard support, and basic accessibility without extra work. In JavaScript-heavy apps, those behaviors become custom features that can be forgotten, partially reimplemented, or broken by design. That shifts HTML-first from a style preference into a reliability strategy.

    Choose stacks by their failure modes, not just their happy-path developer experience. For forms and workflow apps, favor tools whose defaults preserve browser behavior unless you have a clear reason to override it.

      Attribution:
    • afavour #1
    • wmanley #1
    • manuhabitela #1
    • zelphirkalt #1
  3. 03

    The React ecosystem still wins on complex UI

    A credible limit on the article’s lesson came from people who had actually built products without heavy frontend frameworks. They said server-rendered HTML and tools like htmx are excellent for CRUD and multipage forms, but the tradeoff shows up when you need rich widgets, OAuth flows, polished edge cases, or off-the-shelf components. In those cases the React ecosystem can save real time. That does not rescue React as the default for every brochure site or utility form, but it does explain why teams stick with it even when they know the output is heavier.

    Do not turn HTML-first into a purity test. Use it as the default for simple workflows, then switch only when the product truly needs the component ecosystem and client-side interaction model.

      Attribution:
    • iamjs #1
    • meander_water #1
    • aturek #1
    • TZubiri #1
  4. 04

    Testing on low-end hardware changes product decisions

    Several commenters argued that teams ship bloated sites because they never feel the pain themselves. Their machines are fast, their networks are good, and their browsers are current. Once you force a site through a cheap Android phone, 3G throttling, or a low-memory desktop, extra JavaScript stops looking abstract and starts looking like abandonment. This landed as a practical product discipline, not nostalgia for old browsers.

    Add low-end device and throttled-network checks to product reviews, not just QA. If key flows are slow there, treat that as a business problem, not a niche accessibility issue.

      Attribution:
    • Joeri #1
    • Telaneo #1
    • alok-g #1
    • McGlockenshire #1
  5. 05

    HTMX can become backend spaghetti fast

    One of the more concrete implementation tips came from people using htmx in production. The warning was that fragment-driven pages get ugly when every partial becomes its own route and template. A cleaner pattern is to keep one handler per page and vary the returned fragment within that boundary, or even render the whole page and let `hx-select` pluck the needed section. That keeps security logic, caching, and reasoning about page state in one place instead of scattering it across pseudo-micro-frontends on the server.

    If you adopt htmx or similar server-driven UI, set routing and template boundaries early. Otherwise you can recreate frontend fragmentation on the backend and lose the simplicity you were chasing.

      Attribution:
    • pphysch #1
    • wild_egg #1
  6. 06

    Progressive enhancement was solved before the SPA era

    A number of experienced web developers pointed out that this is less a new idea than a return to patterns that were standard in Rails, jQuery-era sites, and especially GOV.UK service design. Multipage wizards, server-side sessions, native forms, and JavaScript enhancement were already the playbook for public-facing services. The web platform is better now, so the case for reviving that model is stronger, not weaker. The novelty is that many current teams have never seen it practiced well.

    Look at older public-service patterns before inventing a new frontend architecture for forms. You may be reviving a proven design system, not sacrificing modernity.

      Attribution:
    • aidanbeck #1
    • c-hendricks #1
    • brightball #1
    • sjtgraham #1

Against the grain

  1. 01

    The gain came from design discipline, not Astro

    A meaningful pushback was that the article risks over-crediting the stack choice. The old site was bad because it was badly designed for the users and constraints, not because React made that inevitable. A disciplined team could build a similar flow with React, using native validation, server rendering, and simple interactions. This matters because otherwise teams may swap frameworks and keep the same bad habits.

    Do not expect a move away from React to fix product problems by itself. Tie any rewrite to explicit UX constraints, performance budgets, and supported-device assumptions.

      Attribution:
    • arnorhs #1
    • onion2k #1
    • bastawhiz #1
  2. 02

    Maintenance and hiring can favor mainstream stacks

    Some commenters were uneasy with the post’s one-sided framing because maintainability is social as much as technical. A straightforward Astro or HTML-first app may still be harder for the next team if the org mostly hires React developers, shares React components across projects, or enforces a standard platform. In that setting, unfamiliarity can become real maintenance cost even if the output is technically better.

    When choosing a simpler stack, account for who will inherit it and what your org can staff. A technically cleaner approach can still fail if it sits outside the team’s operating model.

      Attribution:
    • iamjs #1
    • victorbjorklund #1
    • egeozcan #1
  3. 03

    SPAs still make sense for truly stateful apps

    There was also a narrower defense of SPAs from people who remembered why they took over in the first place. Once an application has dense interaction, long-lived client state, and many in-place updates over a long session, the SPA cost gets amortized and the model becomes practical. The mistake is stretching that model onto every form and content site. The article’s example was a bad fit for SPA architecture, not proof that SPA architecture is generally obsolete.

    Reserve SPA complexity for interfaces with sustained, high-frequency interaction. If a workflow mostly navigates between steps and submits forms, that threshold has probably not been met.

      Attribution:
    • fiedzia #1
    • acdha #1
    • zelphirkalt #1

In plain english

Astro ↩
A web framework that defaults to shipping static or server-rendered HTML and only adds client-side JavaScript where you explicitly opt in.
CRUD ↩
Create, read, update, delete, the basic operations used in many simple business applications.
GOV.UK ↩
The United Kingdom government’s central website and design system, often cited for accessible and low-friction public service design.
htmx ↩
A library that lets HTML attributes trigger server requests and update parts of a page without building a full client-side JavaScript app.
HTTP ↩
Hypertext Transfer Protocol, the basic protocol browsers and servers use to request and deliver web pages and data.
OAuth ↩
Open Authorization, a standard way for an app to let users sign in or grant access using another service such as Google.
SPA ↩
Single-page application, a web app that loads a large JavaScript app once and then updates the page dynamically instead of doing full page loads.

Reference links

Frameworks and approaches

  • HTML Triptych proposal
    Proposed browser features to strengthen form-and-REST patterns discussed in the article.
  • GOV.UK guidance on progressive enhancement
    Official guidance cited as backing the HTML-first, public-service approach.
  • Hotwire Native
    Suggested as a way to wrap server-driven web apps for mobile while keeping most UI on the web side.
  • Hyperview
    Shared as another server-driven mobile UI approach that avoids frequent app-store review cycles.

Counterpoints and related reading

Implementation examples and tools

  • validation-enhancer
    Form validation helper mentioned in the article and discussed in comments.
  • formisch
    Another form-validation project suggested as relevant to HTML-first form handling.
  • Handling form errors in htmx
    Shared as a practical example of using the browser’s built-in validation APIs with htmx.
  • Datastar checkbox demo
    Used to argue that server round trips can still feel responsive in a streaming HTML model.
  • cattlecloud/webtools
    Shared as a Go helper library for HTMX and web app patterns.
  • cattlecloud/litesql
    Shared as a SQLite helper library in the same Go plus HTMX stack.

Broader context

  • PWA Score
    Cited to rebut claims that PWA support has been removed on major mobile platforms.
  • PIAAC 2023 national results
    Used to support the point that many adults struggle with digital problem solving, regardless of age.
  • The origin of complexity
    Suggested reading on why unnecessary software complexity accumulates.