El costo en IA de los frameworks de JavaScript

Artículo original ↗ Discusión en Hacker News ↗

Los frameworks front-end de JavaScript están siendo reevaluados a la luz de la programación asistida por IA, con un benchmark pequeño que sugiere que herramientas como Astro, HTMX y Nuxt pueden permitir que los agentes construyan sitios centrados en contenido más rápido y barato que frameworks SPA más pesados como Angular. Los comentaristas discuten cuánto importa esto: algunos lo ven como una validación de enfoques más simples, impulsados por el servidor, o de sistemas de componentes al estilo React que reducen la carga cognitiva tanto para humanos como para modelos, mientras que otros subrayan que la elección del framework aún debería estar guiada por la mantenibilidad a largo plazo, la complejidad de las apps reales y la estabilidad del ecosistema, en lugar de micro-benchmarks. Hay un amplio acuerdo en que las pruebas actuales son demasiado simplistas y que las evaluaciones futuras deberían cubrir aplicaciones más complejas y con estado, seguridad y las capacidades cambiantes de los agentes de IA.

Alcance y limitaciones del benchmark

  • Muchos consideran que el benchmark de la app de Pokémon es demasiado pequeño y estático para orientar decisiones del mundo real.
  • Los críticos señalan que le faltan funciones complejas (autenticación, control de acceso, flujos sociales, tiempo real, formularios con validación, desarrollo con varios equipos).
  • Algunos valoran el intento de usar métricas objetivas (tiempo, tokens, LOC) en lugar de “vibes”, pero temen que otros generalicen en exceso.
  • Varios quieren benchmarks de seguimiento sobre apps más complejas e incluso seguridad (por ejemplo, probar el acceso basado en roles con agentes).

Ganadores, perdedores y casos de uso de frameworks

  • Astro, HTMX y Nuxt reciben muchos elogios, especialmente para sitios impulsados por contenido y por su eficiencia en tokens.
  • Algunos destacan que Astro/HTMX brillan en casos de uso estáticos o con mucho contenido; cuestionan cómo se comportan en apps muy interactivas.
  • Angular recibe críticas duras, pero sus defensores argumentan que encaja con apps empresariales grandes y complejas y que se beneficia de su rigidez.
  • Svelte/Solid son elogiados por su elegancia y manejo de asincronía, aunque los resultados aquí decepcionaron a algunos.
  • React es visto ampliamente como el valor predeterminado de facto, especialmente para agentes y tooling; se reconoce que jQuery sigue siendo omnipresente, pero en su mayoría como legado.

SPA frente a enfoques del lado del servidor y estilo HTMX

  • Muchos sostienen que la mayoría de los sitios deberían renderizar HTML en el servidor con JS mínimo, apuntando a HTMX, Turbo/Stimulus y patrones tipo LiveView.
  • Otros responden que las SPA complejas aún necesitan un rico estado del lado del cliente para la capacidad de respuesta, actualizaciones optimistas y grandes conjuntos de funciones.
  • Varios informan que la IA tiene más dificultades con escenarios complejos de HTMX/estado que con SPA de React/Svelte.

Por qué existen los frameworks (para humanos y agentes)

  • Argumentos a favor de los frameworks: reducen la carga mental, estandarizan patrones, facilitan la incorporación/contratación, proporcionan componentes reutilizables y centralizan la gestión del estado.
  • Argumentos en contra de los frameworks: boilerplate y peso innecesarios, dependencia impulsada por contratación/HR más que por necesidad, rigidez y churn de migración a largo plazo.
  • Algunos sugieren que, con IA escribiendo código, las abstracciones pueden aportar menos valor, mientras que otros dicen que la IA también necesita abstracciones estables y se beneficia de frameworks conocidos incorporados en su entrenamiento.

Agentes de IA, “vibe coding” y mantenibilidad

  • Las experiencias difieren: algunos reportan un excelente “vibe coding” con React/Nuxt/Astro; otros encuentran que los agentes producen desorden enmarañado sin una estructura temprana.
  • Hay preocupación por prototipos enormes de un solo archivo que superan las ventanas de contexto; algunos abogan por refactorizar en componentes o usar plantillas basadas en frameworks desde el inicio.
  • Continúa el debate sobre si los frameworks o el JavaScript sin framework minimizan el uso total de tokens por parte del agente y las tasas de error.

Rendimiento, DOM y debates de lenguaje

  • Un subconjunto discute el rendimiento del DOM frente a actualizaciones de HTML basadas en cadenas, plantillas y funciones experimentales del navegador.
  • Otros se preocupan por riesgos de seguridad (XSS) y por la complejidad práctica de los enfoques basados en cadenas.
  • Debates paralelos cubren la sobrecarga de async/await, el tamaño de los bundles de WASM y si el JS moderno se ha vuelto estéticamente y cognitivamente desagradable.