Most JavaScript programmers default to their ride-or-die frameworks, but such loyalties can hinder them when they task AI agents with doing their dirty work. Human-friendly tools aren't necessarily the most effective ones for the model-powered minions. "One of my pet peeves with the web development community is that so many of the decisions we make are vibes-based,” wrote Seattle-based Nolan Lawson, currently a developer at AI security firm Socket. That’s an understatement; the JavaScript wars have been well underway for over a decade now, with each new framework promising to cure the woes of last year’s release. Not wanting these vibey biases to seep into the realm of AI, Lawson created a benchmark to compare how different JavaScript frameworks perform under the same agentic model. He subsequently ran the test on 12 JavaScript frameworks, publishing the results in a post that compared each framework in terms of build cost, maintainability, and end-user performance of their agent-built apps. The results are illuminating. In general, agents tend to work more efficiently with server-centric frameworks than with client-heavy “Single-Page App” (SPA) frameworks (which should tickle for React haters). But the biggest take-away should be less controversial: agents best utilize those frameworks that favor convention, API stability, and concision. How to compare JavaScript frameworks For the experiment, Lawson wrote a set of instructions for a Claude Code agent to build a basic Pokémon web application using the PokéAPI. The model used the identical setup on 12 different frameworks and JavaScript stacks: Angular, Astro, Gracile with Lit, Hono with htmx, vanilla JavaScript with Vite, Next.js, Nuxt, Qwik, React Router, TanStack Start, SolidStart, and SvelteKit. Lawson evaluated each stack across five independent sandbox runs; the repeated iterations smoothed the variance in the model’s performance. To verify the resulting app met the specs, Lawson deployed a custom automated test suite that queried the browser's accessibility tree to ensure interactive elements like buttons and inputs weren’t faked – a shortcut LLMs occasionally take. Lawson also used Google Lighthouse to measure transfer size and runtime performance. If the frameworks specified official MCP servers, Claude plug-ins, and agent-skill files, Lawson provided them as resources to the agents (though they weren’t always consulted). Otherwise, he did not mandate any specific architecture for rendering the app. Comparing 12 JavaScript frameworks The differences between the most cost-effective builds and the most expensive ones are substantial, to say the least, with the best lapping the efforts of the stragglers. If you want to build a Pokéworld cost-effectively, the strongest bet is on Hono paired with htmx. This tag-team of technologies had the most economical run, with a median cost of $2.67 per Pokéapp. Perhaps this is not surprising, given that the duo runs entirely on the server, thereby eliminating a whole set of checks required to synchronize an architectural split between client and server. It also helped minimize the code, which resulted in fewer output tokens being consumed. Nearly as effective was Astro ($2.76). Like Hono/htmx, Astro does everything server-side. Server-side data crunching also helped Astro achieve the fastest median time to build and test the app, at 8.2 minutes. Nuxt ($2.82) was the most cost-effective option for an SPA-like approach. Nuxt renders code on the server that gets hydrated on the client. Nuxt is actually built on Vue.js, but is “opinionated,” eliminating a lot of boilerplate that the agent must write. Nuxt also handles data transfer and file routing internally, which is more code not to fuss over. It’s also worth noting Nuxt consumed the fewest tokens of the bunch (3.85 million), though that did not make it the cheapest, given how Claude charges different rates for input and output tokens. Nuxt produced the app in 1,415 lines of code, which is second only to Hono/htmx's 1,370 lines. Overall, these top three frameworks were within the margin of error of each other, which means any one of them could have gotten the top score depending on what kind of day the LLM was having. Some of the more traditional frameworks lumbered way behind, however. A SvelteKit-based app cost $4.28 to generate, with the agent repeatedly going back to the SvelteKit documentation to get a better handle on how the recently-updated Svelte works. Angular was the most expensive way for an agent to build an app, costing $4.97 while taking 17.2 minutes and chewing up 9.76 million tokens (with the agent failing to even finish a working app in two of its five attempts). All the resulting apps aced the Lighthouse accessibility and performance tests. It’s a pretty simple app to render, Lawson acknowledged. Astro’s app had the fastest loading time (called Largest Contentful Paint or LCP) of 810 ms, while the slowest frameworks in the cohort – Next.js (2,090 ms) and TanStack Start (2,028 ms) – took more than twice as long to deliver the goods, perhaps because of all the JavaScript they shipped to the client. Gold stars for all Lawson hopes this work will set the stage for applying a bit more rigor in selecting frameworks for AI jobs, now that developers won’t have to do the actual heavy lifting themselves. But a few developers on Hacker News pointed out AI efficiency isn’t the only factor to consider. There’s the human component of maintaining the framework as well. “After a decade of React, I'm not going to go learn htmx or any other marginally better same-shaped tool for a new project, especially when it'd degrade my ability to review and debug another actor's work product,” one wrote. After all, the frameworks themselves might evolve with the help of AI, minimizing their differences over time. “Besides a rewrite to another framework using AI, another option is to modernize the framework with AI instead,” someone else noted. ®
/s3/static.nrc.nl/wp-content/uploads/2026/11/03094230/041126CUL_2036390847_sven.jpg)
/s3/static.nrc.nl/wp-content/uploads/2026/11/02125218/041126BIN_2038100606_cuba.jpg)
