O custo oculto dos frameworks JavaScript para IA

A comunidade de desenvolvimento web tem um problema crônico: toma decisões baseadas em "vibes" em vez de evidências. Durante anos, desenvolvedores adotaram frameworks por causa da "boa experiência de desenvolvimento" (DX) que pareciam oferecer, justificando retrospectivamente a escolha com argumentos como "o virtual DOM é rápido!" — sem nunca medir se aquilo realmente entregava mais valor. Alex Russell já chamou isso de "a década perdida do frontend"; Baldur Bjarnason rotulou programação como uma "pop culture" de modismos.

Mas a era dos agentes de IA mudou tudo — ou pelo menos deveria mudar. Quando um desenvolvedor já não digita o código linha a linha, mas sim dá instruções a um agente de IA (como o Claude Code), a noção de "experiência de desenvolvimento" perde o sentido. O que importa agora é quão barato e eficiente um framework é quando o agente precisa construí-lo. E é exatamente isso que o engenheiro Nolan Lawson mediu em outubro de 2026 em um benchmark ambicioso: o mesmo aplicativo Pokémon, construído cinco vezes com cada um de doze frameworks JavaScript diferentes, usando agentes de IA.

O experimento

O cenário é simples, mas deliberadamente escolhido. Lawson construiu um aplicativo Pokédex — um catálogo de dados sobre Pokémon com pesquisa, filtros e detalhes de cada criatura — usando a PokéAPI como fonte de dados. Para cada um dos doze frameworks (Next.js, Nuxt, SvelteKit, Angular, Astro, Hono+htmx, Qwik, SolidStart, React Router, TanStack Start, Gracile+Lit e JavaScript puro com Vite), ele instruiu um agente Claude Code (modelo Opus 5.5) a construir o mesmo aplicativo e rodou a operação cinco vezes por framework. O resultado foi avaliado em quatro dimensões: custo em dólares da API, tempo real de execução (wall-clock), quantidade de tokens processados e pontuações de desempenho e acessibilidade no Lighthouse.

Os resultados revelaram um padrão claro e, para muitos desenvolvedores, desconfortável. O framework mais barato para construir com IA foi o Hono+htmx, com uma mediana de US$ 2,67 por build. Astro veio em segundo (US$ 2,76) e Nuxt em terceiro (US$ 2,82). No extremo oposto, Angular era o framework mais caro, com US$ 4,97 — praticamente o dobro do mais barato. SvelteKit (US$ 4,28) e Gracile+Lit (US$ 4,65) também se mostraram significativamente mais caros. O vanilla JavaScript com Vite ficou em quarto lugar (US$ 2,98), surpreendentemente competitivo, desafiando a noção de que frameworks sempre valem a pena.

O que torna esses números particularmente relevantes é que eles não medem apenas o custo inicial de construção. A quantidade de linhas de código gerada impacta diretamente o custo de manutenção futura. Hono+htmx produziu cerca de 1.370 linhas de código; Angular, 2.009 — aproximadamente 70% mais código. Como Lawson observa, "no era dos agentes, isso ainda pesa mais", porque cada edição futura também consome tokens, afetando "o custo literal de manter um codebase ao longo do tempo".

Por que alguns frameworks são mais caros

Os motivos revelados pelo benchmark são reveladores. O SvelteKit, um dos frameworks mais caros, teve seus agentes lendo o guia de migração para a versão 3 em cada execução — o que provavelmente ocorreu porque essa versão era nova demais para estar nos dados de treinamento do Opus 5.5. O Gracile (um framework de web components) foi ainda mais problemático: os agentes não conheciam o framework e precisaram clonar o repositório ou ler o código compilado dos node_modules. O Angular, por sua vez, simplesmente gerava mais e mais código a cada iteração.

A adoção de ferramentas de IA também variou dramaticamente entre os frameworks. O React Router teve o skill tool instalado e usado em 100% das execuções; o Nuxt teve seu MCP instalado, mas nunca foi usado pelos agentes; o Next.js teve seu skill file lido apenas uma vez em cinco execuções. Essa variabilidade demonstra a natureza estocástica dos LLMs — o mesmo agente pode tomar decisões radicalmente diferentes para o mesmo problema, apenas por sorteio.

Qualidade: o que o Lighthouse não mostra

Curiosamente, as pontuações de desempenho, acessibilidade e CLS (Cumulative Layout Shift) do Lighthouse estavam praticamente saturadas em todos os frameworks — não havia variação significativa. O que realmente importou foi o tamanho do JavaScript enviado ao cliente. Astro enviou efetivamente 0 KiB de JavaScript (era um site estático gerado no build); Hono+htmx enviou apenas 18 KiB; enquanto Next.js enviou 142 KiB, React Router 115 KiB e TanStack Start 118 KiB. Para usuários em conexões móveis, a diferença entre 0 e 142 KiB de JavaScript é a diferença entre carregar instantaneamente e esperar.

A métrica de LCP (Largest Contentful Paint) foi ainda mais reveladora, embora altamente variável — o que Lawson admite como limitação. Em geral, o LCP puniu Single Page Applications (SPAs) e recompensou Multi-Page Applications (MPAs), o que não é surpresa: MPAs pintam HTML diretamente no servidor, enquanto SPAs precisam primeiro executar o JavaScript do cliente e fazer chamadas à API para buscar os dados.

O que isso significa para o futuro do frontend

O benchmark de Lawson levanta uma questão que poucos querem fazer: em 2026, quando agentes de IA estão escrevendo a maior parte do código, os frameworks JavaScript deveriam ser projetados pensando primeiro na legibilidade para máquinas, não na DX para humanos? A resposta provavelmente está no meio — mas os dados mostram que frameworks mais leves e com menos abstração (Hono, Astro, Nuxt) entregam melhor custo-benefício para desenvolvimento assistido por IA. E que frameworks com camadas extras de abstração (Angular, SvelteKit) podem estar entregando menos valor do que o marketing promete.

O próprio Lawson admite as limitações do experimento: o Pokédex é um aplicativo de conteúdo, mais parecido com uma Wikipedia do que com um Figma ou Gmail, e não representa a complexidade de apps altamente interativos. Mas para uma fatia significativa da web moderna — dashboards, catálogos, aplicações baseadas em dados — o Pokédex é exatamente o tipo de app que os agentes estão construindo todos os dias. E os números não mentem.

A pergunta que fica é se os autores de frameworks vão levar esses dados a sério ou se a comunidade vai continuar decidindo por vibes — especialmente porque, ironicamente, a maioria das equipes de framework já está usando agentes de IA internamente. Se o seu próprio agente sabe que Astro é mais barato que Angular para construir, por que insistir na escolha "por feeling"?

Fontes: Nolan Lawson, Web Standards Daily, GitHub — agent-framework-benchmark

✓ Fontes independentes cruzadas e verificadas antes da publicação