AI Coding Cost Benchmark: Angular Consumes Nearly Double Tokens vs Hono+htmx

Over the past decade, competition among JavaScript frameworks has centered on developer experience (DX), runtime performance, and engineering efficiency. Frameworks like React, Angular, and Vue have cultivated massive developer ecosystems, where framework selection is often closely tied to a team’s technical expertise, development habits, or even personal preferences.

However, as AI Agents take on an increasing share of code-writing tasks, these evaluation criteria may be shifting. More developers are beginning to ask: Which framework is best suited for AI Agent programming? Which one allows models to complete tasks faster, consume fewer tokens, and generate more maintainable code?

Recently, Nolan Lawson, former Performance Program Manager for Microsoft Edge and veteran web developer, tasked AI Agents with building the same Pokémon application using 12 different JavaScript frameworks. He compared them across dimensions including development cost, token consumption, build time, final product performance, and code maintenance scale.

The results showed that for the same application development task, the cheapest option—Hono+htmx—had a median cost of $2.67, while Angular reached $4.97, nearly double the former. In terms of token consumption, Angular used 9.76 million tokens, compared to Hono+htmx’s 4.26 million—a difference of approximately 2.3x. Meanwhile, applications generated by different frameworks exhibited significant variations in JavaScript bundle size, browser main thread blocking time, and overall code volume.

Lawson uses this data to pose a question worthy of industry-wide reconsideration: When developers no longer write every line of code themselves, should the technology choices historically driven by developer experience remain unchanged?

Same App, Nearly Double the Cost for Angular, Over Twice the Token Consumption

The test included 12 frameworks: Angular, Astro, Gracile+Lit, Hono+htmx, Next.js, Nuxt, Qwik, React Router, SolidStart, SvelteKit, TanStack Start, and a solution using Vanilla JavaScript/TypeScript with Vite (no UI framework).

The experiment uniformly used Claude Opus 5.5 with "High" reasoning intensity, requiring the Agent to use the latest version of each respective framework. Each framework was run five times in principle, with each iteration completed in an isolated sandbox. The author did not inform the Agent in advance that the app would undergo Lighthouse performance and accessibility testing, nor did he specify whether SSR or CSR must be used, or require specific performance optimization strategies.

To ensure fairness, Lawson installed official MCP servers, Skills, or Claude Code plugins for each framework (where available) but did not force the Agent to utilize these tools. Regarding CSS, he did not restrict the method, only prohibiting Tailwind, Bootstrap, or other component frameworks, and enforced visual consistency through unified design specifications.

To control variables as much as possible, Lawson did not allow the Agent to develop arbitrary project types. Instead, all frameworks were required to build the same Pokédex application based on the PokéAPI. The app featured a list of Pokémon, their attributes, moves, and game version data, supporting search and filtering functions.

It should be noted that two Angular tests encountered special circumstances: Although the Agent generated an SSR application, it refused access from sources other than localhost, failing to meet test requirements. Lawson treated these instances as non-compliant completions and did not rerun them. Consequently, code size and performance metrics rely only on the three valid test results, while cost statistics retain all five runs.

First, looking at the most intuitive metric: development cost. Results show that Hono+htmx, Astro, and Nuxt excelled in AI construction costs: Hono+htmx ranked first at $2.67, followed by Astro at $2.76, and Nuxt at $2.82. Conversely, Angular, Gracile+Lit, and SvelteKit had relatively higher costs. Specifically, Angular’s estimated cost per build reached $4.97, approximately 1.86 times that of Hono+htmx.

These prices represent token cost estimates calculated by Claude Code based on API pricing, rather than actual independent bills paid by Lawson. Lawson utilized the $100/month Claude Max subscription plan, meaning the tests fell within his existing subscription quota.

Behind the cost differences, token consumption and development time exhibit similar trends.

In terms of development time, Astro performed best, with a median build time of 8.2 minutes, followed by Hono+htmx at 8.6 minutes, and Nuxt at 9 minutes. Angular required 17.2 minutes, more than double Astro’s time.

Token consumption also follows a similar pattern. Nuxt consumed approximately 3.85 million tokens per build, Astro about 4.13 million, and Hono+htmx around 4.26 million. Angular, however, reached 9.76 million tokens, roughly 2.5 times that of Nuxt. TanStack Start, SolidStart, and React Router also showed relatively high token consumption, reaching 7.07 million, 7.13 million, and 7.58 million respectively.

This implies that even when using the same model and identical task requirements, choosing different frameworks can lead to significant disparities in the cost and time required for an Agent to complete the work.

However, Lawson also cautioned that costs and token usage exhibit significant volatility. For instance, the median cost for React Router is approximately $1 higher than that of Hono+htmx. Yet, the cheapest single test run for React Router cost only $2.82, which is still lower than the most expensive run for Hono+htmx at $3.19. Therefore, differences observed in a single test should not be interpreted as inherent, fixed cost disparities between frameworks.

Overall, SvelteKit, Gracile+Lit, and Angular incurred relatively higher development costs. One possible reason for SvelteKit’s high cost is its recent version release; the Agent read the SvelteKit v3 migration guide during every test, likely because Opus 5.5’s training data lacked sufficient information about the new version.

The situation with Gracile was even more pronounced. Due to the Agent’s unfamiliarity with the framework, it sometimes cloned the entire repository or even read compiled source code within node_modules. Angular’s high costs were primarily associated with the scale of the generated code.

This highlights an often-overlooked issue: how easily a framework can be understood by models is becoming a new variable in technology selection.

MCP and Skills Are Not as Effective as Expected; Agents Often Ignore Them

To prevent certain frameworks from being disadvantaged due to a lack of AI tool support, Lawson installed official MCP servers, Skills, or Claude Code plugins for each framework wherever possible. However, experimental results showed that the Agent’s actual utilization of these tools was inconsistent.

Lawson argued that this scenario accurately reflects real-world AI coding practices. Ordinary developers do not repeatedly use uppercase commands to force the Agent to call MCPs or read Skills; many users do not even proactively configure these tools.

Additionally, Lawson explained the rationale behind selecting specific testing approaches. Hono+htmx was chosen to include htmx in the comparison while positioning Hono as a JavaScript-based alternative to Rails/Django-style solutions. Gracile+Lit was selected to represent the Web Components ecosystem.

For Vanilla, Lawson instructed the Agent to use native JavaScript or TypeScript without any UI framework, built via Vite. The results indicated that the native approach did not outperform all frameworks; in terms of cost and token consumption, it was inferior to some frameworks.

Generated Applications Also Exhibit Performance Differences

While the previous section addressed the question of "how much does it cost for AI to write code," the performance of the final generated applications answers a different question: given the tokens spent, what is the quality of the delivered product?

Lawson used Lighthouse to conduct performance and accessibility tests on the generated applications. He emphasized that software development should not solely pursue low costs but must also ensure the final product is efficient and user-friendly.

First, looking at the overall Lighthouse scores, the differences among the 12 frameworks were minimal. Except for Vanilla, which had a CLS (Cumulative Layout Shift) of 0.111 and a performance score of 97, and Angular with a performance score of 98, and TanStack Start with 99, the remaining solutions generally achieved perfect scores of 100 for both performance and accessibility, with CLS typically at 0.

Since the overall scores were already close to perfection, Lawson further compared specific metrics such as JavaScript transfer size, Total Blocking Time (TBT), and Largest Contentful Paint (LCP).

In terms of JavaScript transfer size, Astro was the lightest, at just 0KiB (test range 0–1KiB); Vanilla was 7KiB, Gracile+Lit was 8KiB, and Hono+htmx was 18KiB. In contrast, Next.js reached 142KiB, TanStack Start was 118KiB, and React Router was 115KiB.

TBT warrants particular attention. Total Blocking Time measures the duration during which the browser’s main thread is blocked by long tasks. Higher values indicate that the main thread is occupied for longer periods during page loading, potentially impacting user interaction responsiveness.

In the experiments, the median TBT for Astro, Gracile+Lit, Hono+htmx, SvelteKit, and Vanilla was 0ms; TanStack Start was 1ms, Qwik was 3ms, SolidStart was 11ms, React Router was 17ms, and Nuxt was 40ms. Next.js reached 71ms, while Angular hit 103ms.

Lawson specifically noted that TBT is not solely determined by JavaScript transfer size. For example, Angular’s JavaScript transfer size was 93KiB, lower than Next.js’s 142KiB, yet its TBT was higher. This indicates that the actual execution burden on the browser’s main thread depends not only on the amount of code downloaded but also on factors such as code parsing, execution, and framework runtime mechanisms.

Regarding LCP (Largest Contentful Paint), Astro ranked first at 810ms, followed by Gracile+Lit at 956ms, Hono+htmx at 978ms, and Qwik at 979ms. Next.js reached 2090ms, TanStack Start was 2028ms, and Angular was 1954ms.

LCP variance was significantly higher than that of other metrics. Lawson discovered that one Next.js test did not use lazy loading for images, while the other four did, directly causing the discrepancy in results. Similar fluctuations were observed with Astro and Vanilla, likely related to resource prioritization and changes in how LCP identifies the largest element.

Overall, LCP tests tend to favor Multi-Page Applications (MPAs) that can return HTML quickly, rather than Single-Page Applications (SPAs) that require waiting for client-side JavaScript execution and often need multiple network requests to fetch data. From this experiment, it appears that LCP is largely correlated with JavaScript bundle size. However, Qwik is an exception: although it uses client-side routing and is technically an SPA, its final score was close to MPA solutions.

Nevertheless, Lawson pointed out that Lighthouse and Core Web Vitals inherently have a bias against SPAs. Therefore, these results should not be interpreted as SPAs being inferior to MPAs in all application scenarios.

Less Code May Mean Cheaper AI Maintenance

Beyond development costs and final product performance, Lawson also compared the scale of code generated by each framework, using it as a simple metric for maintainability.

Instead of employing complex metrics like cyclomatic complexity, he directly counted non-empty lines of source code. The results showed that Hono+htmx generated only 1,370 lines of code, the fewest among all solutions; Nuxt generated 1,415 lines, Astro 1,461 lines, and Next.js 1,539 lines. Angular reached 2,009 lines, the highest among all solutions.

This set of results drew special attention from Lawson. He quoted Rich Harris, the creator of Svelte: "Frameworks are not tools for organizing code, but tools for organizing thought."

In Lawson's view, the significance of frameworks has always been to reduce the amount of code requiring maintenance. In the era of Agents, this issue becomes even more critical because code scale ultimately affects token consumption—not just the cost of initial code generation, but also the cost of every subsequent modification, debugging session, and refactoring effort.

In this experiment, Hono+htmx achieved the same application functionality as Angular's ~2,009 lines of code with approximately 1,370 lines—about 68% of Angular's volume—while also offering lower development costs and faster speed.

Lawson emphasized that conciseness is not the only value worth pursuing in a framework. However, in a context where AI Agents become the primary producers of code, whether a framework can reduce code scale is clearly worth reintegrating into technology selection criteria.

How Should We Choose Frameworks Now? Developers Are Arguing

In his article, Lawson raised a long-standing issue in the web development community: technology selection often relies on subjective feelings rather than reliable test data. One framework might be marketed as faster or more efficient for development, while another tool is deemed better suited for AI Agents, but these conclusions often lack sufficient experimental evidence.

He argued that as AI Agents gradually take over substantial coding tasks from developers, the logic behind technology selection built around developer experience needs to be re-evaluated. If developers no longer write code line-by-line themselves, then when choosing a framework, greater emphasis should be placed on whether the Agent can stably understand documentation and complete tasks, and whether the resulting application is sufficiently efficient and easy to maintain.

After Lawson published his experiment, it immediately sparked debate within the community. Some advocated returning to native technologies, while others believed frameworks had become even more important.

One group of developers believes that AI is weakening the necessity of traditional frameworks. Previously, one of the greatest values of frameworks was helping human developers organize code, manage complex state, and improve collaboration efficiency—tasks that can now be delegated to AI. For websites with relatively simple interactions, such as content display and information retrieval, using raw HTML, CSS, and native JavaScript may be more economical than introducing large frameworks like React. Some even stated bluntly that since AI can already write code, there is no need to continue relying on complex technical systems originally established for the convenience of human developers.

Another group argues that frameworks are not obsolete in the AI era; they may actually be more important. One developer shared that after trying to use native JavaScript with large models, code defects gradually increased, leading them to switch back to React. React's stable API and relatively mature programming patterns are easier for models to understand and help reduce chaos during implementation. Others believe that frameworks provide necessary engineering constraints for long-term projects, reducing the probability of Agents repeatedly stumbling in complex codebases.

The discussion extended to enterprise software engineering management. One developer shared their team's journey over less than five years: moving from Backbone, Angular, React, Ember, Next.js, Vue, and Svelte, eventually returning to Angular and React. Frequent refactoring allowed managers to claim new project achievements but potentially left behind hastily delivered code and accumulating technical debt. Part of the reason for the frequent churn in JavaScript frameworks over the past decade was not necessarily driven by business needs, but by corporate hiring practices, technology selection trends, and management chasing popular technologies.

Other developers countered that frameworks are not merely products of technological trends. For commercial software and large applications, frameworks are backed by continuously maintained open-source communities, mature component ecosystems, and validated engineering practices. If enterprises completely abandon existing frameworks and build their own state management, reactive updates, and component systems, they may simply reinvent a framework with higher maintenance costs. While AI can accelerate code maintenance, it does not mean that software maintenance itself has disappeared.

However, this experiment is not a framework leaderboard directly applicable to all projects. The test covered only a Pokémon application primarily focused on content display with relatively simple interactions, which cannot represent complex dashboards, email systems, design tools, or large enterprise applications. Lawson hopes this experiment demonstrates that in the era of AI programming, technology selection can still be validated through data and benchmarks, rather than continuing to rely on community reputation and subjective judgment.

For software teams already heavily dependent on AI Agents, this experiment raises a question worth reconsidering: previously, developers chose frameworks to make writing code more comfortable for themselves; in the future, choosing a framework may also require considering whether it makes AI write code with fewer tokens, faster development, less generated code, and lower subsequent maintenance costs.

One developer shared that when using AI to build HTMX projects, simple pages worked well. However, once complex forms and state management were involved, the agent frequently encountered issues such as slow page loads and lost state. He initially believed that switching to React might allow the agent to complete the task in one go. Ultimately, however, he resolved these problems by adding testing constraints, enabling the agent to iteratively fix the issues while retaining the HTMX approach. The final performance even exceeded what he had expected from a React implementation.

Conversely, others argue that React’s popularity and abundance of existing code examples make it easier for models to grasp its development patterns. Whether a tech stack is suitable for AI depends not only on the framework itself but also on the model’s training data, documentation quality, tooling support, and the complexity of actual tasks.

While there is no consensus in this discussion, one shift is becoming clear: AI is forcing developers to reevaluate traditional technology selection criteria. Frameworks are no longer just tools to help humans write code more conveniently; they must also prove their ability to help agents understand projects more accurately, generate fewer errors, and reduce long-term maintenance costs.

References:

https://nolanlawson.com/2026-10-28/the-ai-cost-of-javascript-frameworks/

https://news.ycombinator.com/item?id=50323088

https://github.com/nolanlawson