Evaluación Empírica de Frameworks JavaScript en la Era de Agentes de Codificación

El problema fundamental que aborda este estudio es la prevalencia de decisiones de diseño de software basadas en "sensaciones" o "vibras" en la comunidad de desarrollo web, en lugar de en evidencia empírica. Históricamente, la elección de frameworks JavaScript ha estado influenciada por la experiencia del desarrollador (DX) y justificaciones post-hoc, como la supuesta velocidad del Virtual DOM. Sin embargo, en la "era agéntica" donde los Large Language Models (LLMs) generan código, la restricción de DX disminuye, lo que debería abrir la puerta a una evaluación más objetiva.

Este trabajo propone que, incluso con agentes de codificación, la necesidad de benchmarks rigurosos es más crítica que nunca. La hipótesis es que las diferencias en la eficiencia y el rendimiento de los frameworks, cuando son implementados por agentes, pueden ser cuantificadas y que estas métricas deberían guiar las decisiones de arquitectura. La relevancia actual radica en la optimización de costos y recursos computacionales asociados a la generación de código por IA, y en la búsqueda de una base más sólida para la selección de tecnologías en un panorama de desarrollo en constante evolución.

Arquitectura del Sistema

El benchmark se estructura alrededor de la construcción de una aplicación Pokémon no trivial utilizando la PokéAPI. El sistema de prueba emplea agentes de codificación (Claude Opus 5.5) instruidos para construir la aplicación con un framework JavaScript específico (ej. Next.js, Nuxt, SvelteKit, Hono+htmx, Angular, Astro, Qwik, SolidStart, TanStack Start, React Router, Gracile+Lit, Vanilla JS con Vite). Cada agente opera en un entorno aislado (sandbox) sin conocimiento previo de las pruebas de rendimiento.

La arquitectura de evaluación incluye un conjunto de pruebas de conformidad para asegurar que la aplicación generada cumple con las especificaciones funcionales, evitando "trampas" del agente. Las métricas clave recolectadas son el tiempo de desarrollo (wall-clock time), el costo en tokens de LLM, las líneas de código generadas y las puntuaciones de Lighthouse (Performance, Accessibility, CLS, JavaScript bytes, Total Blocking Time, Largest Contentful Paint). Se realizan múltiples iteraciones (5 por framework, excepto Angular con 3) para mitigar la naturaleza estocástica de los LLMs y las variaciones de Lighthouse. La distinción entre Single Page Applications (SPAs) y Multi Page Applications (MPAs) es un factor implícito en las métricas de rendimiento, con una inclinación natural de Lighthouse a favorecer las MPAs en ciertas métricas como LCP.

Fundamentos Teóricos

Este estudio se alinea con la disciplina de la ingeniería de software empírica, que busca validar hipótesis y comparar tecnologías a través de experimentos controlados y mediciones cuantitativas. Conceptos como la "ingeniería de rendimiento" y la "evaluación comparativa de sistemas" son centrales, donde la recolección de métricas objetivas es fundamental para la toma de decisiones. Aunque no cita directamente un paper fundacional, el enfoque de "menos hype, más stack" resuena con la crítica a la "programación como cultura pop" de Baldur Bjarnason y la "década perdida del frontend" de Alex Russell, que abogan por un retorno a la rigurosidad y la evidencia en la selección de herramientas.

La variabilidad observada en los resultados, especialmente la naturaleza estocástica de los LLMs, subraya la importancia de la estadística experimental y la replicación para obtener conclusiones robustas, un principio fundamental en cualquier investigación científica. La evaluación de la "mantenibilidad" a través de las líneas de código se relaciona con métricas de complejidad de software propuestas por autores como McCabe (complejidad ciclomática) o Halstead (métricas de complejidad de software), aunque el estudio opta por una métrica más directa y fácilmente cuantificable para la era agéntica.