The AI cost of JavaScript frameworks

nolanlawson.com · Nov 1, 2026

Nolan Lawson benchmarked Claude Opus 5.5 building the same Pokémon data application with 12 JavaScript framework setups, measuring estimated API cost, build time, token use, code size, spec conformance, and Chromium Lighthouse results. Each framework generally received five sandboxed runs; Angular received three valid runs after two generated SSR applications failed reverse-proxy requirements. Agents were told to use current framework versions and received official MCP tools or skills where available, but their use varied substantially.

Median estimated generation costs ranged from $2.67 for Hono plus htmx to $4.97 for Angular. Astro had the shortest median build duration at 8.2 minutes, while Angular took 17.2 minutes. Hono plus htmx generated the fewest lines of code, 1,370, compared with Angular’s 2,009. Lighthouse performance and accessibility scores were nearly uniform: most implementations scored 100 for both, while all scored 100 for accessibility. Astro shipped no client-side JavaScript in the median result and had the fastest reported median LCP at 810 ms; Next.js shipped 142 KB of JavaScript and recorded a 2,090 ms LCP. Results came from one relatively content-focused application, and Lawson noted variability in agent behavior and Lighthouse measurements. He also noted that Lighthouse metrics favor multi-page applications over SPAs and that other application types or metrics could yield different results.

Read original ↗

What people are saying

The thread treated the article less as a verdict on web frameworks than as a test of what makes AI-assisted coding cheap, reliable, and maintainable.

What readers liked

Astro’s strong showing makes a compelling case that content sites can buy faster AI generation and lower spend by avoiding unnecessary client-side…
Modernizing a mature framework with agents and a solid test suite can be safer than a wholesale rewrite, turning AI into a practical maintenance…

Concerns raised

The benchmark’s small content-style app flatters frameworks designed for that niche and cannot establish how they fare on live, highly interactive…
Completion price and speed are weak proxies for a framework decision when years of maintenance, security posture, team familiarity, and code…

View discussion ↗

Read full discussion analysis

Source: Hacker News · Based on 15 sampled comments · Analyzed Nov 1, 2026

Discussion overview

The thread treated the article less as a verdict on web frameworks than as a test of what makes AI-assisted coding cheap, reliable, and maintainable. Several readers liked the evidence that a low-JavaScript, content-oriented approach can sharply reduce agent time and token spend; Astro in particular looked attractive for the narrow kind of site tested. Others argued that this is exactly why the ranking cannot be generalized: a small content app says little about real-time interactions, dense form validation, or larger long-lived products.

A strong anti-framework current held that agents benefit from plain browser APIs, small bundles, and fewer dependencies because there is less code and abstraction to fit into context. But practical experience pushed back. One reader found that an agent handled a complicated stateful UI poorly in HTMX until extensive tests constrained it, while React was expected to model that job more naturally. Another warned that agent-generated vanilla front ends can collapse into enormous mixed HTML, CSS, and JavaScript files, making later edits slow and fragile unless a framework imposes structure.

Commenters also objected to treating dollar cost and completion time as the only meaningful outputs. They stressed that tests, existing codebases, security history, domain fit, and whether humans can still reason about the result may justify modest extra AI cost. The broad conclusion was not that one framework won, but that AI changes the tradeoffs and makes task-specific evaluation essential.

Points of disagreement

The central fight was whether AI makes frameworks obsolete or makes their structure more valuable. The anti-framework side argued that fewer abstractions, dependencies, and client-side bytes leave agents with less context to manage and let them use stable native APIs directly. The opposing side argued that once an application grows beyond a one-shot demo, disciplined component boundaries and state models prevent agent output from turning into an uneditable, failure-prone blob.

What readers liked

Astro’s strong showing makes a compelling case that content sites can buy faster AI generation and lower spend by avoiding unnecessary client-side JavaScript.
Modernizing a mature framework with agents and a solid test suite can be safer than a wholesale rewrite, turning AI into a practical maintenance tool rather than a migration lottery.
Small vanilla or server-rendered applications can ease an agent’s context burden, since there are fewer packages, smaller bundles, and less framework-specific behavior to track.
Tests can rein in agents on difficult stateful interfaces, allowing an initially unreliable HTMX implementation to become substantially faster and more dependable.

Concerns raised

The benchmark’s small content-style app flatters frameworks designed for that niche and cannot establish how they fare on live, highly interactive, or validation-heavy products.
Completion price and speed are weak proxies for a framework decision when years of maintenance, security posture, team familiarity, and code legibility dominate the real cost.
AI can struggle badly with complex HTMX state, producing slow pages and broken toggles until substantial test coverage forces correctness.
One-shot agent output may begin impressively but can degenerate into a giant interleaved front-end file whose growing context demands make small changes risky.
Poor browser-performance instincts in SPA tooling can turn ordinary DOM work into needless overhead, while users tolerate sluggish web applications more than comparable desktop failures.