Astro y Hono+htmx: los frameworks más baratos con agentes

Construir la misma app con agentes cuesta el doble según el framework

Construir la misma aplicación con un agente de IA cuesta entre US$2,67 y US$4,97 por intento según el framework de JavaScript que elijas. La diferencia —casi el doble— no la decidió la complejidad del producto ni el talento del equipo, sino una línea en el package.json.

El desarrollador Nolan Lawson, conocido por su trabajo sobre rendimiento web, publicó un benchmark en su blog que pone números donde antes había intuición. Su tesis es incómoda para el sector: durante años el ecosistema eligió herramientas por "vibras" —"es rapidísimo", "potencia tu desarrollo"— y en la era de los agentes la costumbre no cambió. Ahora se reescriben frontends enteros porque un framework es "mejor para los agentes", casi siempre sin evidencia.

Para un founder que ya delegó la escritura de código a un agente, esa decisión dejó de ser estética y se volvió una partida de costo recurrente.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Qué midió exactamente el benchmark de Nolan Lawson?

El experimento es directo: diseñar una app pequeña pero no trivial de Pokémon con la PokéAPI —listado, búsqueda, filtros, tipos y movimientos— y pedirle a un agente que la construya con cada framework o meta-framework.

Cada framework se construyó 5 veces y se tomó la mediana, para amortiguar la aleatoriedad de los modelos. La excepción fue Angular, que falló dos veces, así que quedó en 3 iteraciones.
El agente recibió la spec, la instrucción de usar la última versión del framework y los MCP o skills oficiales de cada herramienta, para no acusar al autor de representar mal a ningún framework.
No se impuso arquitectura (SSR o CSR), ni metodología CSS (se prohibió Tailwind, Bootstrap y cualquier librería de componentes), ni se le dijo al agente que sería evaluado con Lighthouse.
El resultado se validó contra una suite de conformidad construida sobre el árbol de accesibilidad, no sobre el DOM, para evitar que el agente hiciera trampa y para no exigir una estructura HTML particular.

El propio autor advierte los límites: es una app de contenido, más cercana a una Wikipedia que a un dashboard complejo; Lighthouse castiga por diseño a las SPA; y todo lo medido es estocástico, porque los LLM son generadores de palabras aleatorias y a veces sacan un dado malo.

Costo: los frameworks orientados a contenido ganan

El ranking de costo por corrida queda así: Hono+htmx (US$2,67), Astro (US$2,76), Nuxt (US$2,82), Vanilla (US$2,98), Next.js (US$3,14), Qwik (US$3,27), TanStack Start (US$3,54), SolidStart (US$3,79), React Router (US$3,81), SvelteKit (US$4,28), Gracile+Lit (US$4,65) y Angular (US$4,97).

Lawson aclara que son precios de API cotizados por Claude Code y no lo que él gastó: trabaja con un plan Max de US$100 al mes. También señala la varianza: la corrida más barata de React Router (US$2,82) sigue siendo más económica que la más cara de Hono+htmx (US$3,19).

¿Por qué los últimos tres son más caros? En SvelteKit los agentes leyeron la guía de migración a la v3 en todas las corridas, probablemente porque es demasiado nueva para estar en los datos de entrenamiento. En Gracile el agente no conocía el framework y clonó el repositorio o leyó el código compilado en node_modules. En Angular el sobrecosto parece seguir al tamaño total del código.

El tiempo y los tokens acompañan al costo: Astro termina en 8,2 minutos y Angular en 17,2; Nuxt consume 3,85 millones de tokens y Angular 9,76 millones. Un detalle relevante: Vanilla (JavaScript o TypeScript con Vite, sin framework de UI) rinde peor que varios frameworks, lo que sugiere que cierta estructura ayuda más que la ausencia total de ella.

Calidad: Lighthouse casi no distingue, pero los bytes de JavaScript sí

El hallazgo más contraintuitivo es que las métricas de Lighthouse están prácticamente saturadas. Casi todos los frameworks sacan 100 en accesibilidad, entre 97 y 100 en performance y 0 en Cumulative Layout Shift, salvo Vanilla con 0,111. Elegir framework "porque es más rápido" con estos números es discutir decimales.

Donde sí aparece la diferencia es en el JavaScript transferido: Astro queda en 0, Vanilla en 7, Gracile+Lit en 8, Hono+htmx en 18, SvelteKit en 36, SolidStart y Qwik en 40, Nuxt en 84, Angular en 93, React Router en 115, TanStack Start en 118 y Next.js en 142, según las cifras que reporta el benchmark.

El Total Blocking Time sigue un patrón parecido: Astro, Gracile+Lit, Hono+htmx, SvelteKit y Vanilla marcan 0, mientras Angular llega a 103, Next.js a 71 y Nuxt a 40. En Largest Contentful Paint, Astro pinta en 810 y Next.js en 2090. La conclusión del autor es la esperada: las arquitecturas MPA que pintan HTML rápido le ganan a las SPA que pintan después de ejecutar JavaScript en el cliente. Qwik es la excepción notable, porque siendo técnicamente una SPA puntúa entre los MPA.

Mantenibilidad: menos líneas de código, menos tokens en el futuro

El dato que más debería importar a un founder está en las líneas de código. Hono+htmx resuelve la app con 1.370 líneas; Angular necesita 2.009, un 47% más. En el medio quedan Nuxt (1.415), Astro (1.461), Vanilla (1.492), Next.js (1.539), React Router (1.564), SvelteKit (1.611), SolidStart (1.630), TanStack Start (1.697), Gracile+Lit (1.717) y Qwik (1.744).

Lawson cita a Rich Harris, creador de Svelte: "los frameworks no son herramientas para organizar tu código; son herramientas para organizar tu mente". Y agrega el giro de la era agéntica: el tamaño del código impacta directamente la cantidad de tokens, incluidos los de futuras ediciones. Menos líneas no es solo elegancia, es costo de mantenimiento literal cada vez que un agente vuelve a tocar el repositorio.

¿Qué significa esto para tu startup?

Antes de reescribir tu frontend "porque es mejor para los agentes", conviene separar lo que este benchmark prueba de lo que no.

Mide tu propio caso antes de migrar. El experimento usa una app de contenido. Si tu producto es un dashboard con mucha interactividad, un editor o una app de productividad, el resultado puede invertirse: el propio autor admite que un benchmark centrado en SPA daría otro ganador. Corre tu versión con tus tareas reales y tus criterios de aceptación.
Si tu producto es intensivo en contenido, prioriza MPA. Astro, Hono+htmx y Nuxt combinan bajo costo de construcción, bajo JavaScript transferido y menos líneas de código. En un sitio de marketing, un blog o un catálogo, esa combinación se traduce en Core Web Vitals mejores sin esfuerzo extra.
Cuenta el costo por tarea terminada, no el precio por token. Un agente inspecciona archivos, llama herramientas, corre tests, reintenta pasos y regenera output antes de cerrar una tarea. Como reportó TechRepublic al comparar modelos de coding, un modelo con precio por token más alto puede salir más barato si termina el trabajo en menos pasos, y el estudio de Microsoft que cita ese medio encontró que el uso regular de agentes de código se asoció con un 24% más de pull requests fusionados, aunque la adopción, la antigüedad del repositorio y la capacidad de revisión afectaron el resultado. La misma lógica aplica al framework: importa cuántos tokens consume hasta que la app funciona.
No des por sentado que los MCP y skills ayudan. Lawson sospecha que "la cosecha actual de MCPs y skills puede estar haciendo más daño que bien". En su test, el MCP de Nuxt nunca se usó, el agente de Next.js leyó el skill file en 1 de 5 corridas y el de TanStack Start descubrió los suyos en 2 de 5. Instalar la herramienta oficial no garantiza que el agente la aproveche.

Vale la pena mirar también la tendencia del mercado: unite.ai reportó que Fortytwo lanzó una API de inferencia que, según la compañía, redujo 24,7% los tokens en tareas de ingeniería de software frente al mismo modelo corriendo solo. El sector entero se está moviendo hacia medir costo por trabajo completado, no costo por token emitido.

Conclusión

El benchmark de Nolan Lawson no corona un framework ganador ni pretende ser la última palabra: su objetivo declarado es demostrar que en la era del vibe coding todavía se puede decidir con evidencia en lugar de con vibras. Y deja una pregunta que todo founder que ya no escribe código a mano debería hacerse: si delegaste la construcción a un agente, ¿qué apego real tienes a las decisiones que tomaste cuando escribías línea por línea?

La respuesta práctica no es migrar mañana. Es medir. El código del benchmark está abierto en GitHub para que cualquiera lo bifurque, lo critique o lo mejore, y el propio autor invita a que los frameworks compitan por un mejor resultado.