El costo oculto de los frameworks JavaScript para IA

La comunidad de desarrollo web tiene un problema crónico: toma decisiones basadas en "vibes" en lugar de evidencia. Durante años, los desarrolladores adoptaron frameworks porque parecían ofrecer una buena experiencia de desarrollo (DX), justificando retrospectivamente la elección con afirmaciones como "el virtual DOM es rápido" — sin medir nunca si realmente entregaban más valor. Alex Russell ha llamado a esto "la década perdida del frontend"; Baldur Bjarnason etiquetó la programación como una "pop culture" de modas pasajeras.

Pero la era de los agentes de IA ha cambiado el juego — o al menos debería haberlo cambiado. Cuando un desarrollador ya no escribe código línea por línea, sino que le da instrucciones a un agente de IA (como Claude Code), la noción de "experiencia de desarrollo" se vuelve algo irrelevante. Lo que importa ahora es qué tan barato y eficiente es un framework cuando un agente de IA necesita construir con él. Y eso es exactamente lo que el ingeniero Nolan Lawson midió en octubre de 2026 en un benchmark ambicioso: la misma app de Pokémon, construida cinco veces con cada uno de doce frameworks JavaScript diferentes, usando agentes de IA.

El experimento

El planteamiento es sencillo pero deliberado. Lawson construyó una Pokédex — un catálogo de datos de Pokémon con búsqueda, filtros y detalles de cada criatura — usando la PokéAPI como fuente de datos. Para cada uno de los doce frameworks (Next.js, Nuxt, SvelteKit, Angular, Astro, Hono+htmx, Qwik, SolidStart, React Router, TanStack Start, Gracile+Lit, y JavaScript puro con Vite), le instruyó a un agente Claude Code (modelo Opus 5.5) que construyera la misma app y ejecutó la operación cinco veces por framework. Los resultados se evaluaron en cuatro dimensiones: costo en dólares de la API, tiempo real de ejecución, cantidad de tokens procesados y puntuaciones de rendimiento y accesibilidad en Lighthouse.

Los resultados revelaron un patrón claro y, para muchos desarrolladores, incómodo. El framework más barato para construir con IA fue Hono+htmx, con una mediana de US$ 2,67 por build. Astro llegó segundo (US$ 2,76) y Nuxt tercero (US$ 2,82). En el extremo opuesto, Angular era el más caro, con US$ 4,97 — prácticamente el doble del más barato. SvelteKit (US$ 4,28) y Gracile+Lit (US$ 4,65) también resultaron significativamente más costosos. El JavaScript vanilla con Vite quedó en cuarto lugar (US$ 2,98), sorprendentemente competitivo, desafiando la noción de que los frameworks siempre valen la pena.

Lo que hace estos números particularmente relevantes es que no miden solo el costo inicial de construcción. La cantidad de líneas de código generadas impacta directamente el costo futuro de mantenimiento. Hono+htmx produjo alrededor de 1.370 líneas de código; Angular, 2.009 — aproximadamente 70% más código. Como observa Lawson, "en la era de los agentes, esto pesa aún más", porque cada edición futura también consume tokens, afectando "el costo literal de mantener un codebase a lo largo del tiempo".

Por qué algunos frameworks son más caros

Los motivos revelados por el benchmark son reveladores. SvelteKit, uno de los frameworks más costosos, tuvo sus agentes leyendo la guía de migración a la versión 3 en cada ejecución — lo que probablemente ocurrió porque esa versión era demasiado nueva para estar en los datos de entrenamiento del Opus 5.5. Gracile (un framework de web components) fue aún más problemático: los agentes no conocían el framework y tuvieron que clonar el repositorio o leer el código compilado de los node_modules. Angular, por su parte, simplemente generaba más y más código en cada iteración.

La adopción de herramientas de IA también varió dramáticamente entre los frameworks. React Router tuvo el skill tool instalado y usado en el 100% de las ejecuciones; Nuxt tuvo su MCP instalado, pero los agentes nunca lo usaron; Next.js tuvo su skill file leído solo una vez en cinco ejecuciones. Esta variabilidad demuestra la naturaleza estocástica de los LLMs — el mismo agente puede tomar decisiones radicalmente diferentes para el mismo problema, simplemente por azar.

Calidad: lo que Lighthouse no muestra

Curiosamente, las puntuaciones de rendimiento, accesibilidad y CLS (Cumulative Layout Shift) del Lighthouse estaban prácticamente saturadas en todos los frameworks — no había variación significativa. Lo que realmente importó fue el tamaño del JavaScript enviado al cliente. Astro envió efectivamente 0 KiB de JavaScript (era un sitio estático generado en el build); Hono+htmx envió solo 18 KiB; mientras que Next.js envió 142 KiB, React Router 115 KiB y TanStack Start 118 KiB. Para usuarios en conexiones móviles, la diferencia entre 0 y 142 KiB de JavaScript es la diferencia entre cargar instantáneamente y esperar.

La métrica de LCP (Largest Contentful Paint) fue aún más reveladora, aunque altamente variable — lo que Lawson reconoce como limitación. En general, el LCP castigó las Single Page Applications (SPAs) y recompensó las Multi-Page Applications (MPAs), lo que no es sorpresa: las MPAs pintan HTML directamente en el servidor, mientras las SPAs necesitan primero ejecutar el JavaScript del cliente y hacer llamadas a la API para obtener los datos.

Qué significa esto para el futuro del frontend

El benchmark de Lawson plantea una pregunta que pocos quieren hacerse: en 2026, cuando los agentes de IA están escribiendo la mayor parte del código, ¿deberían los frameworks JavaScript estar diseñados pensando primero en la legibilidad para máquinas, no en la DX para humanos? La respuesta probablemente está en el medio — pero los datos muestran que los frameworks más ligeros y con menos capas de abstracción (Hono, Astro, Nuxt) entregan mejor costo-beneficio para el desarrollo asistido por IA. Y que los frameworks con capas extra de abstracción (Angular, SvelteKit) pueden estar entregando menos valor del que su marketing promete.

El propio Lawson reconoce las limitaciones del experimento: el Pokédex es una app de contenido, más parecida a Wikipedia que a Figma o Gmail, y no representa la complejidad de apps altamente interactivas. Pero para una franja significativa de la web moderna — dashboards, catálogos, aplicaciones basadas en datos — el Pokédex es exactamente el tipo de app que los agentes están construyendo todos los días. Y los números no mienten.

La pregunta es si los autores de frameworks van a tomar estos datos en serio o si la comunidad continuará decidiendo por vibes — especialmente porque, irónicamente, la mayoría de los equipos de framework ya están usando agentes de IA internamente. Si tu propio agente sabe que Astro es más barato que Angular para construir, ¿por qué insistir en la elección "por feeling"?

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

✓ Fuentes independientes cruzadas y verificadas antes de la publicación