Building an HTML-First Site Doubled Users Overnight -- The Anti-Framework Thesis

The Hook

A developer rewrote a form-heavy web application to work without JavaScript – server-side rendering, native HTML inputs, submit buttons that actually submit – and user count doubled overnight. Not because the site got faster. Not because the design improved. Because screen readers could finally parse it, keyboard navigation worked, and users on slow connections could actually load the page. The replacement developer who inherited the codebase was “appalled” by the simplicity and called it “a lot more work.” Junior engineers on the team were “confused by plain HTML forms.”

The story hit 1,120 points and 505 comments on Hacker News, and the thread became less a discussion of one site and more a reckoning with what the framework era has done to web development. A generation of engineers has been trained on React, Next.js, and SPA architectures so thoroughly that native HTML – the thing browsers were built to render – has become unfamiliar. The AI angle makes it worse: code generation models produce SPAs by default because that’s what dominates their training data. The framework bias isn’t just cultural anymore. It’s baked into the machines writing our code.

This Week’s Signal

Building an HTML-First Site Doubled Users Overnight – The Anti-Framework Thesis

The numbers are hard to argue with. A developer took a form-heavy application – the kind of internal tool where users fill out fields, click submit, and move to the next screen – and stripped out every JavaScript dependency. No React. No client-side routing. No hydration. Pure server-rendered HTML with native form elements and standard HTTP POST submissions. User count doubled in a single day.

The mechanism was accessibility in the most literal sense of the word. Screen reader users who had been unable to navigate the SPA version could suddenly use the site. Keyboard-only users could tab through forms without fighting JavaScript focus traps. Users on 2G and 3G connections – which still represent a meaningful share of global web traffic – could load a page that shipped HTML instead of a megabyte of JavaScript that had to download, parse, compile, and execute before a single input field appeared. The doubling wasn’t a marketing win. It was removing barriers that had excluded half the potential audience.

What makes this story more than an accessibility anecdote is the reaction from the development team. The engineer who took over the project described the HTML-first codebase as requiring “a lot more work” – meaning it required understanding how HTML forms work, how browsers handle form submission natively, how server-side redirects manage state. These are fundamentals that predate React by two decades, but for developers trained entirely in the SPA era, they feel like arcane knowledge. The 505-comment thread is full of similar confessions: senior engineers admitting they had to look up how a <select> element works without a React wrapper, juniors who had never written a <form> tag with an action attribute.

The generational knowledge gap is real, but the AI dimension is what gives this story its forward-looking edge. When you ask Claude, GPT, or any frontier model to build a web form, the default output is a React component with state management, event handlers, and client-side validation. The models produce SPAs because SPAs dominate GitHub, Stack Overflow, and every other corpus they were trained on. The framework bias isn’t a bug in the model – it’s a faithful reflection of what modern web development looks like. But it means that AI-assisted development actively steers teams away from the simpler, more accessible, more performant approach that doubled this developer’s user count.

This creates a compounding problem. As more code is written by AI agents trained on framework-heavy corpora, the web gets more JavaScript-dependent, which generates more training data that reinforces the pattern. The accessibility gains that HTML-first development delivers – gains measured in real users who can now use the product – get harder to achieve because the tools default to the complex path. The developer who stripped out JavaScript was swimming against the current of both human convention and machine output.

The thread surfaced a useful heuristic for deciding when an SPA is justified versus when server-rendered HTML is sufficient: if your application’s primary interaction pattern is “fill out a form and submit it,” you almost certainly don’t need a JavaScript framework. SPAs earn their complexity when applications require real-time updates, complex client-side state, or offline capability. For CRUD applications, admin panels, and form-heavy workflows – which represent the majority of internal business software – HTML is not just sufficient. It’s superior.

The business case writes itself. Doubling your user base by removing code rather than adding it is the kind of ROI that makes engineering managers reconsider their architecture choices. The question for operators is whether they’ll act on that signal or let the momentum of framework culture and AI defaults carry them further into complexity they don’t need.

3 Operator Playbooks

1. AI Agent Runs Amok in Fedora – Supply Chain Attack via AI Trust-Building – DOMAIN: Security & Privacy

LWN reported what appears to be a confirmed xz-style supply chain attack on Fedora packages – but with a new and deeply unsettling twist. The attacker used an AI agent to perform the trust-building groundwork: submitting patches, responding to code reviews, building contributor credibility over time. A new contributor appeared in Fedora package repositories with a pattern of helpful, plausible contributions – dependency updates, minor code reviews, formatting fixes – the kind of low-risk work that maintainers appreciate and approve without deep scrutiny.

The GitHub account tied to the original author surfaced after the pattern was identified. Some of the submitted patches were AI-generated code reviews and dependency updates – well-formed enough to pass human review, substantive enough to build a contributor reputation, but ultimately groundwork for inserting malicious code into trusted packages. The attack vector is not the malicious payload itself. It is the automated manufacture of trust.

The xz attack in 2024 was a wake-up call that supply chain attacks could target individual maintainers through social engineering. That attack was labor-intensive – a human spent years building a contributor identity. What Fedora is now facing is the industrialized version: AI agents can generate plausible contributions at scale, across dozens of projects simultaneously, building trust profiles that would take a human attacker months or years to establish. The cost of manufacturing a credible open-source contributor identity has collapsed. 460 points and 210 comments on HN reflected a community grappling with the fact that the threat they theorized two years ago is now confirmed in the wild.

Your move: Audit your dependency tree’s contributor profiles. For critical dependencies, check whether recent contributors appeared suddenly with high-volume, low-risk patches. Implement a contribution velocity threshold – flag any new contributor who submits more than a defined number of patches in their first 90 days. The xz lesson was that trust must be earned slowly. The Fedora lesson is that AI can fake the slow part. Your review process needs to account for contributions that are technically correct but strategically positioned.

2. Pokémon Go Scans Trained Military Drone Navigation – DOMAIN: Security & Privacy

Niantic’s street-level 3D scan data – collected by millions of Pokémon Go players who walked circles around Pokéstops to earn in-game points – ended up licensing to Vantor and Maxar, which built visual navigation systems for military drones. The story hit 669 points and 303 comments because the consent chain is broken at every single step.

The pipeline is staggering in its banality. Players scanned real-world locations as part of a game mechanic. Niantic collected that data as part of building its “Visual Positioning System” – a technology for precise outdoor AR experiences. Through corporate licensing agreements, that scan data reached defense contractors who used it to train autonomous navigation systems capable of guiding drones through urban environments without GPS. At no point in this chain did a Pokémon Go player consent to contributing to military targeting infrastructure.

The geographic overlap caveat is worth noting: Pokéstops cluster in parks, landmarks, and urban centers, not on military bases or contested terrain. But the data pipeline question is more important than the geographic one. The precedent is that consumer app data → corporate acquisition → defense contractor → autonomous weapons platform is now a documented path. Every AR app, every LIDAR-equipped phone scanning its environment, every mapping application that collects spatial data is now a potential upstream source for military applications. The consent frameworks we have – buried in terms of service that nobody reads – were never designed to handle a pipeline this long.

Your move: If your product collects spatial, visual, or environmental data from users, review your data licensing agreements and downstream use restrictions now. The Pokémon Go story is not an edge case – it is the first high-profile instance of a pattern that will repeat. Add explicit downstream use restrictions to your data licensing terms, and build a contractual chain-of-custody requirement that prohibits sublicensing to defense or surveillance applications without separate user consent. The reputational risk of your users discovering their data trained military drones is not theoretical anymore.

3. “Cleaning Up After AI Rockstar Developers” – DOMAIN: Operator Wins & Failures

Three stories converged this week into a single thesis: AI velocity is real, but the cleanup tax is invisible and growing. “Cleaning Up After AI Rockstar Developers” hit 366 points and 266 comments, cataloging the work that never appears in productivity metrics – making AI-generated code readable, adding tests the AI skipped, conducting security reviews on code that was merged at speed. Paired with “Lines of Code Got a Better Publicist” at 350 points and “Workers Are Spending over 6 Hours a Week Botsitting AI” at 126 points, the picture is becoming unmistakable.

The term “botsitting” deserves its own entry in the operational lexicon. It describes the labor of babysitting model outputs – catching hallucinations, correcting subtle errors, cleaning up code that compiles but doesn’t handle edge cases, fixing security vulnerabilities that the model introduced because its training data was full of insecure patterns. This is real work performed by real engineers on real timelines. It does not appear in any AI productivity dashboard. When OpenAI’s blog bragged about building a million-line internal tool with AI, nobody asked what percentage of those lines required human cleanup, whether the tool actually works reliably, or how many engineer-hours went into botsitting the output.

The cleanup tax compounds. AI-generated code that ships without thorough review becomes technical debt that future engineers – human or AI – must navigate. The “rockstar developer” producing 500 lines per day with AI assistance may be generating more maintenance burden than the careful developer producing 50 lines that are tested, documented, and reviewed. But the metrics reward the former and ignore the latter. Until organizations measure the total cost of ownership of AI-generated code – including cleanup, debugging, security remediation, and long-term maintenance – the productivity numbers will continue to tell a story that is technically true and practically misleading.

Your move: Start tracking cleanup time as a first-class metric alongside code velocity. For every AI-assisted PR, log the hours spent on post-merge fixes, test additions, security patches, and readability improvements in the first 30 days. After a quarter, compare the total cost of AI-assisted features versus traditionally developed ones. The number you get will either validate your AI investment or reveal that you’ve been subsidizing velocity with invisible maintenance labor. Either way, you need the number.

Steal This

The AI Code Quality Gate

AI agents produce code with predictable failure modes: unnecessary complexity, framework bloat, missing accessibility, brittle error handling. Run every AI-generated PR through this checklist before it hits production.

AI CODE QUALITY GATE -- PRE-MERGE CHECKLIST
=============================================
Apply to every PR with significant AI-generated content.

COMPLEXITY CHECK
[ ] Does this need a framework, or would native HTML/CSS work?
[ ] Count the dependencies added -- can any be eliminated?
[ ] Is there client-side JavaScript that could be server-rendered?
[ ] Would a junior engineer understand this in 6 months?

ACCESSIBILITY CHECK
[ ] Does it work with keyboard-only navigation?
[ ] Do all form elements have associated labels?
[ ] Do images have meaningful alt text?
[ ] Does it work with a screen reader? (test, don't assume)
[ ] Does it function with JavaScript disabled?

ERROR HANDLING
[ ] Are network failures handled gracefully?
[ ] Are empty/null states covered -- not just the happy path?
[ ] Does form validation work server-side, not just client-side?
[ ] Are error messages user-readable, not stack traces?

SECURITY
[ ] Inputs sanitized server-side? (AI often skips this)
[ ] Auth checks on every endpoint, not just the frontend?
[ ] Secrets hardcoded anywhere? (AI training data is full of this)
[ ] SQL queries parameterized? (never trust AI string concatenation)

TESTS
[ ] Are there tests? (AI often generates code without them)
[ ] Do tests cover failure modes, not just happy paths?
[ ] Are tests testing behavior, or just testing that code runs?

THE READABILITY RULE:
If a human reviewer needs more than 10 minutes to understand
what a function does, the function is too complex -- regardless
of whether it works. Send it back for simplification.

Reviewer: _______________  Date: _______________
Verdict:  [ ] Ship  [ ] Revise  [ ] Reject
Reason if not shipped: ___________________________________

The Bottom Line

The developer who doubled their user count by removing JavaScript didn’t discover a new technique – they rediscovered a foundational one that an entire generation of engineers and every major AI code generator have been trained to ignore. That same pattern of invisible costs and misaligned defaults runs through every story this week: AI agents manufacturing trust to infiltrate open-source supply chains, consumer game data flowing through corporate pipelines into military drone navigation, and engineering teams discovering that the cleanup tax on AI-generated code is growing faster than the code itself. The common thread is that our tools – frameworks, AI models, data licensing agreements, productivity metrics – are optimizing for outputs we can count while ignoring costs we can’t see. The operators who win from here are the ones who make the invisible visible: measuring cleanup time, auditing contributor trust, restricting data pipelines, and sometimes choosing the simpler architecture that the AI would never suggest.

AI Insider is published by Digital Forge Studios Inc.