Infrastructure & Efficiency

Coding Agents Cost $2.67 to $4.97 per App, Depending on the Framework

Lighthouse scores were nearly saturated, so JavaScript bytes and blocking time separated the frameworks, though agent runs are stochastic and the app is one content-heavy holotype.

75 points41 comments

Nolan Lawson ran the same small Pokémon app through coding agents five times per JavaScript framework, then measured cost, tokens, wall-clock time, Lighthouse scores and lines of code. Hono+htmx was cheapest at a median $2.67 per run; Angular was dearest at $4.97 and slowest at 17.2 minutes, with SvelteKit and Gracile+Lit also in the expensive tier.

Each framework used its official MCP or skills where one existed, and agents were not told the output would be scored on performance and accessibility, though they were given the conformance suite. Lawson stresses the variance: agent runs are stochastic, LCP is unstable, and Angular failed to produce a measurable app twice.

He calls the app one content-heavy holotype, not a complex dashboard.

Key takeaways

  • Cost tracks tokens and time: Nuxt used 3.85M tokens over 9.0 minutes, Astro 4.13M over 8.2 minutes, and Angular 9.76M over 17.2 minutes. SvelteKit, Gracile+Lit and Angular formed the expensive tier.
  • Lines of code ran from 1,370 for Hono+htmx to 2,009 for Angular. Lawson ties code size to future token spend, since every later edit pays for the context it occupies.
  • MCP and skill adoption was uneven: TanStack Start's agent found its skill files in 2 of 5 runs, Nuxt's MCP was never used, and Next.js read its skill file once. Lawson attributes this to LLM stochasticity rather than framework quality.
  • Agents were not told about the Lighthouse testing and were forbidden from pre-generating static HTML, and Lawson deliberately withheld performance techniques such as lazy-loading, fetchpriority and Speculation Rules to approximate typical vibe-coding.
  • Lawson suspects current MCPs and skills may do more harm than good, and invites forks with more iterations, other agents, other browsers and other app types.

What people think

Frameworks as a hiring filter

Frameworks are cast as an institutional bargain that spares employers from training developers and eases candidate screening, with the human cost landing on teams whose problems fall outside the framework's constraints. The reading is contested: front-end stacks are usually chosen by the developers who use them, frameworks begin as developer projects, and their constraints rarely block work a browser could do anyway.

Who pays for framework maintenance

The strongest economic case for a framework is that a vendor and its volunteers absorb maintenance, so a bespoke stack means paying for library code and the product built on it. Roll-your-own rarely produces a clean abstraction; historically it produced thousands of lines of jQuery. Agentic maintenance workflows may be shrinking the surface that needs maintaining, which would weaken the outsourcing argument.

HTML strings, templates and partial updates

DOM manipulation is expensive because elements bind to JavaScript objects lazily, so the proposed alternative is emitting HTML strings or templates, or using Chrome's experimental declarative partial updates to stream fragments for content-heavy pages. Objections: string-built HTML invites injection, the partial-updates API is experimental and single-browser, and WASM is dismissed on download size, a dismissal rebutted by the claim that WASM binaries are compact by design.

Agent fit depends on problem shape

A complex form with interdependent state was where an agent struggled in htmx: pages took 30 seconds to load, state dropped, and toggles broke after dependency changes, while a React rewrite would likely have worked first try. Tests added to keep the agent honest eventually produced an htmx version faster than the React alternative, suggesting the feedback loop matters more than the framework.

Hand-coding persists as AI spend concentrates

Hand-written code is expected to persist for years, though not necessarily as paid employment. The economic argument is that most developers still write code by hand and that AI spending is concentrated among venture-funded startups while large firms cap it, so forum enthusiasm overstates how widely agents have displaced manual work.

JavaScript ergonomics and async/await

Modern JavaScript's walls of const and async/await are judged ugly, and its event-driven model puts everything somewhere else rather than here and now. One reply goes further, calling async/await a probable mistake and preferring callbacks, whose indentation forced refactoring the way Lisp-style code does.