Hono combinado con htmx fue el stack de JavaScript más barato de construir en una prueba directa de agentes de programación con IA, y Angular fue el más caro. El benchmark, publicado por un desarrollador web, le pidió a Claude Opus 5.5 construir la misma aplicación de Pokémon en 12 frameworks y midió cuánto costó producir cada una.

¿Cómo se realizó el benchmark de programación con IA?

La aplicación es un sitio pequeño, pero no trivial, que obtiene datos de la PokéAPI. Los usuarios pueden listar Pokémon con sus tipos, movimientos y datos del juego, y luego buscarlos y filtrarlos. Cada agente se ejecutó en un entorno aislado y se verificó con un conjunto de pruebas de conformidad basado en el árbol de accesibilidad, lo que evitó que los agentes simplemente generaran HTML estático de antemano. Cuando un framework ofrecía un servidor MCP oficial o habilidades para agentes, se les indicó a los agentes que los usaran. El autor ejecutó cada framework cinco veces y usó la mediana, excepto en el caso de Angular, que produjo dos aplicaciones rotas y se reportó con tres ejecuciones.

¿Cuál framework de JavaScript fue el más barato para construir con agentes de programación con IA?

Las cifras de costo provienen de los precios de la API que reporta Claude Code, no del gasto real del autor. Él paga una suscripción mensual fija, por lo que las cifras son una aproximación. Hono con htmx tuvo una mediana de 2,67 dólares por ejecución, seguido de cerca por Astro con 2,76 dólares y Nuxt con 2,82 dólares. En el otro extremo, SvelteKit costó 4,28 dólares, Gracile con Lit 4,65 dólares y Angular 4,97 dólares. El autor señaló que los rangos se superponen, por lo que la ejecución más barata de React Router seguía siendo menos costosa que la ejecución más cara de Hono.

Los frameworks más caros mostraron algunos patrones consistentes. En todas las ejecuciones de SvelteKit, los agentes leyeron la guía de migración de SvelteKit v3, que el autor sospecha que es demasiado reciente para aparecer en los datos de entrenamiento del modelo. Gracile era menos conocido para los agentes, que clonaron su repositorio o leyeron el código fuente compilado de node_modules. El costo de Angular siguió el tamaño general de su código.

El tiempo y el uso de tokens siguieron un orden similar. Astro tuvo la construcción más corta, con una mediana de 8,2 minutos, y Angular la más larga, con 17,2 minutos, en un rango de 9,8 a 23,7. Nuxt usó la menor cantidad de tokens, con una mediana de 3,85 millones, mientras que Angular usó la mayor, con 9,76 millones. El autor dijo que Vanilla, que significa Vite con TypeScript y sin framework de interfaz, fue sorprendentemente más lento y costoso que varios frameworks, lo que, según él, sugiere que un framework puede ayudar incluso cuando no es necesario.

Los resultados de Lighthouse estuvieron muy agrupados. La accesibilidad obtuvo 100 en los 12 frameworks, y el rendimiento estuvo entre 97 y 100. El Cumulative Layout Shift fue cero para todos, excepto Vanilla. El dato más revelador fue la cantidad de JavaScript que enviaba cada página. Astro envió prácticamente nada, 0 kilobytes. Vanilla envió 7 KiB y Hono con htmx envió 18 KiB. Next.js envió 142 KiB, la cantidad más alta de todos los frameworks probados. El Largest Contentful Paint varió mucho entre ejecuciones y, en general, favoreció a los sitios renderizados en el servidor, que muestran HTML antes de que se ejecute el código del lado del cliente. El autor afirmó que la diferencia en Next.js se debió en gran parte a que una aplicación no cargaba las imágenes de forma diferida, mientras que las otras cuatro sí lo hacían.

Angular tuvo un problema propio. En dos ejecuciones, el agente construyó una aplicación renderizada en el servidor que rechazaba cualquier solicitud que no viniera de localhost, a pesar de que las instrucciones indicaban que la aplicación estaría detrás de un proxy inverso. El autor consideró esto como un incumplimiento de la especificación y no volvió a ejecutar esas iteraciones.

¿Por qué Angular fue el más costoso en el benchmark de programación con IA?

El tamaño del código es donde el autor encontró el contraste más claro. Hono con htmx tuvo una mediana de 1.370 líneas de código fuente no vacías. Angular tuvo 2.009. El autor escribió que Hono con htmx podía hacer aproximadamente el mismo trabajo que Angular con cerca del 70 por ciento del código, lo cual importa en un flujo de trabajo agéntico porque más código significa más tokens para futuras ediciones.

El autor señala varias limitaciones. La prueba cubrió un solo tipo de aplicación, un sitio con mucho contenido y poca interactividad. Los resultados fueron ruidosos: los agentes a veces se desviaron por tangentes, y la métrica del elemento más grande de Lighthouse podía elegir imágenes diferentes de una ejecución a otra. El uso de las herramientas oficiales también fue desigual. El MCP de Nuxt nunca se usó, y los agentes de Next.js leyeron su archivo de habilidades en solo una de cada cinco ejecuciones. Lighthouse y Core Web Vitals también tienden a favorecer los sitios estáticos y renderizados en el servidor sobre las aplicaciones de una sola página, por lo que el autor espera que los resultados sean diferentes para paneles o herramientas interactivas.

El código del benchmark está en GitHub, y el autor invitó a otros a ejecutarlo o bifurcarlo. También dijo que sospecha que los MCP y las habilidades actuales podrían estar causando más daño que beneficio, y que los autores de frameworks podrían mejorar sus resultados. Su argumento principal es que los desarrolladores deben probar sus suposiciones sobre las herramientas, en lugar de confiar en afirmaciones sobre velocidad o compatibilidad con agentes que llegan sin evidencia.

Questo articolo è stato scritto con l'assistenza dell'IA.
News Factory APP - notizie agentiche per potenziare il tuo SEO e AEO.