Imagine you're running a cooking competition where every contestant gets the same recipe but a different kitchen. Some kitchens have one knife and one burner. Others have a sous vide, a Thermomix, fourteen specialized pans, and a manual the size of a phone book. The question isn't which kitchen is fancier — it's which kitchen lets a competent but literal-minded cook (your AI agent) actually produce a good meal fastest, cheapest, and with the fewest fires. That's what this benchmark does for JavaScript frameworks. The committed claim: when AI agents build the same non-trivial app across 12 JavaScript frameworks, simpler and lighter-weight tools (Hono+htmx, Astro, Nuxt) consistently produce cheaper, faster, and higher-quality output than heavier or more complex ones (Angular, Gracile+Lit, SvelteKit). The author ran each framework five times through Claude Opus 5.5 in sandbox, building a Pokémon reference app against the PokéAPI, then evaluated cost, time, tokens, Lighthouse performance, and accessibility scores — with a conformance test suite to prevent agent cheating. The results are striking in their consistency. Hono+htmx costs $2.67 median per run; Angular costs $4.97 — nearly double. Build time follows the same curve: Astro at 8.2 minutes versus Angular at 17.2. Token consumption spans from Nuxt's 3.85M to Angular's 9.76M. But the real story is in quality: frameworks with lower abstraction overhead and server-side rendering defaults produced better Lighthouse scores out of the box. The agent wasn't told to optimize for performance — it just built what the framework encouraged, and the framework's defaults determined the outcome. The methodology is honest about its limits in ways that matter. The author acknowledges the app is a content-heavy read site (closer to Wikipedia than Figma), that LLM outputs are stochastic, that Lighthouse itself is noisy, and that MCP/skill usage varied wildly across runs — some agents ignored their own tools entirely. Five iterations per framework with median reporting is the right move for noisy data, and the conformance suite based on accessibility tree rather than raw DOM avoids penalizing frameworks for structural differences like shadow DOM. What makes this genuinely useful is the multi-dimensional measurement. Cost, time, and tokens are interesting but expected (more code = more tokens = more money). The quality dimension is where frameworks diverge in ways developers should care about. A framework that saves you $1 per build but ships inaccessible, slow pages is extracting from your users to subsidize your workflow. The finding that vanilla JavaScript underperforms several frameworks is counterintuitive and important — it suggests that good framework defaults provide genuine value to AI agents, not just to human developers. The experiment also quietly demolishes several vibes-based claims circulating in the ecosystem. The narrative that newer frameworks are 'better for agents' gets no support here — Hono+htmx, one of the simplest pairings, leads on cost. The idea that MCPs and agent skills dramatically improve outcomes is undermined by the inconsistent usage data: Nuxt's MCP was never used, Next.js's skill files were read in only 1/5 runs. The stochastic nature of agent tool adoption means that framework ergonomics for agents may matter less than the framework's inherent complexity and default rendering strategy. The biggest limitation is the single holotype. A content-based read-heavy app favors SSR-first frameworks and penalizes client-heavy ones. An interactive app (spreadsheet, design tool, real-time collaboration) could invert these rankings entirely. The author knows this and says so. But for the large class of web applications that are fundamentally about displaying and searching content — which is most of them — this is the first real data point in a conversation that has been entirely vibes until now.
