Frameworks de JavaScript: coste de programar con IA y cómo medirlo
Hono+htmx tuvo la menor mediana del coste estimado de API en el benchmark de 12 frameworks de Nolan Lawson; Angular tuvo la mayor. Compara costes, tiempo, tokens y líneas de código. Distingue el uso observado de herramientas de las explicaciones causales y realiza una prueba con Claude Code que registre la caché, los intentos fallidos y las comprobaciones de aceptación.
Índice
Para una aplicación centrada en contenido, empieza por Hono+htmx y Astro si importa el coste de programar con IA. En el estudio de Nolan Lawson, Hono+htmx tuvo la menor mediana del coste estimado de API: $2.67, frente a $4.97 de Angular. Si ya tienes un proyecto, compara una modificación representativa antes de cambiar de framework.
¿Qué framework tuvo el menor coste de IA?
Usa estos resultados para elegir qué frameworks probar en una aplicación centrada en contenido. Lawson publicó el experimento el 28 de octubre de 2026. Las ejecuciones y mediciones publicadas usaron Claude Code 2.1.310 con claude-opus-5-5 y el nivel de esfuerzo high.
Cada agente creó la misma aplicación de PokéAPI con búsqueda, filtros y páginas de detalle. La tabla reúne los resultados publicados a fecha de 2026-11-06. Las versiones corresponden a los paquetes del experimento; no son recomendaciones de instalación actuales.
| Framework y versión probada | Coste estimado de API, USD: mediana (mín.–máx.) | Minutos | Tokens, millones | Líneas de código fuente |
|---|---|---|---|---|
| Hono 4.13.14 + htmx 2.0.11 | $2.67 ($2.23–$3.19) | 8.6 | 4.26 | 1,370 |
| Astro 7.4.2 | $2.76 ($2.16–$3.63) | 8.2 | 4.13 | 1,461 |
| Nuxt 4.6.2 | $2.82 ($2.39–$4.25) | 9.0 | 3.85 | 1,415 |
| Vanilla con Vite 8.3.5 | $2.98 ($2.24–$3.37) | 10.1 | 5.00 | 1,492 |
| Next.js 16.4.3 | $3.14 ($2.58–$4.13) | 10.9 | 4.99 | 1,539 |
| Qwik 1.20.2 / 1.20.3 | $3.27 ($2.35–$3.80) | 10.7 | 5.64 | 1,744 |
| TanStack Start 1.169.4 | $3.54 ($3.11–$3.96) | 10.3 | 7.07 | 1,697 |
| SolidStart 2.1.0 | $3.79 ($2.84–$4.81) | 11.2 | 7.13 | 1,630 |
| React Router 8.5.0 | $3.81 ($2.82–$3.97) | 12.5 | 7.58 | 1,564 |
| SvelteKit 3.1.0 | $4.28 ($3.59–$4.65) | 10.8 | 8.53 | 1,611 |
| Gracile 0.11.0 + Lit 3.3.3 | $4.65 ($3.92–$5.07) | 12.1 | 9.04 | 1,717 |
| Angular 22.2.3 | $4.97 ($3.19–$6.82) | 17.2 | 9.76 | 2,009 |
Cada métrica tiene una mediana independiente. El coste, el tiempo y los tokens incluyen cinco intentos por framework. El tamaño del código de Angular se calculó con tres aplicaciones porque dos no pudieron medirse detrás del proxy inverso.
Los tokens incluyen entrada sin caché, escrituras de caché, lecturas de caché y salida durante toda la sesión. El recuento de líneas excluye líneas vacías, JSON, lockfiles y pruebas. También excluye archivos generados y copias de los archivos de diseño proporcionados; los comentarios sí cuentan.
Estas cifras en dólares son los costes de API que estima Claude Code. Lawson usó una suscripción, así que no representan sus pagos reales por cada aplicación creada. Tampoco incluyen tu factura de alojamiento ni el tiempo de revisión humana.
Según las medianas redondeadas, la diferencia de Angular es $4.97 − $2.67 = $2.30. Su coste equivale a 4.97 / 2.67 ≈ 1.86 veces el de Hono+htmx, aproximadamente un 86% más en esta tarea.
La diferencia entre Next.js y Astro es de $0.38 por aplicación creada, con rangos observados que se solapan. Hono+htmx y Astro solo difieren en $0.09. Estas diferencias justifican una prueba pequeña, pero no una clasificación universal concluyente.
¿Por qué SvelteKit y Angular costaron más?
La lectura adicional de documentación y un mayor volumen de código son explicaciones plausibles, pero el experimento no aísla sus efectos.
Lawson observó que el agente de SvelteKit leía la guía de migración a v3 en cada ejecución. Sugirió que v3 quizá fuese posterior a los datos de entrenamiento del modelo. La guía oficial de migración documenta cambios reales, como trasladar la configuración a Vite. No demuestra qué aprendió el modelo durante el entrenamiento.
Para Gracile, Lawson describe que el agente clonó el repositorio o inspeccionó archivos compilados de node_modules. Eso añade trabajo de investigación. El benchmark no mide qué parte de la diferencia de coste procede de esas lecturas.
Angular generó una mediana de 2,009 líneas de código fuente, frente a 1,370 de Hono+htmx. Esta última cifra supone cerca del 68% de la primera, coherente con la comparación aproximada del 70% de Lawson. Los archivos más grandes pueden aumentar el trabajo de lectura y edición en tareas futuras, pero aquí no se midió el coste de mantenimiento.
Los totales de tokens también requieren cuidado. Nuxt tuvo la mediana de tokens más baja, 3.85 millones, pero no la menor mediana de coste. El uso de caché cambia la relación entre tokens totales y precio. Mantén separadas las categorías de tokens al interpretar el coste.
¿Ayudan los servidores MCP y las skills de los frameworks?
Este benchmark no demuestra que los servidores MCP o las skills reduzcan el coste. Registra un uso desigual de las herramientas disponibles, sin una comparación de cada framework con las herramientas activadas y desactivadas.
Lawson instaló herramientas oficiales cuando estaban disponibles. Varios frameworks no tenían ninguna. Entre sus observaciones figuran:
| Framework | Uso observado en cinco ejecuciones |
|---|---|
| Hono+htmx | El agente usó la herramienta Skill de Hono en 5/5 |
| SvelteKit | MCP usado en 5/5 |
| Nuxt | MCP usado en 0/5 |
| Next.js | Archivos de skills leídos en 1/5; AGENTS.md leído en 2/5 |
| TanStack Start | Encontró los archivos de skills incluidos en el paquete en 2/5 |
Que el MCP de Nuxt no se usara no demuestra que sea ineficaz. El mayor coste de SvelteKit no demuestra que su MCP causara la diferencia. Instalar una herramienta, invocarla y reducir el coste de una tarea completada son resultados distintos.
La guía actual de Next.js distingue la documentación correspondiente a la versión instalada de las skills que coordinan el trabajo. Registra qué recurso usó el agente; no cuentes cada lectura de documentación como una llamada MCP.
Para tu prueba, comprueba la disponibilidad de los servidores con claude mcp list o /mcp. Después, revisa las llamadas reales a herramientas. Compara un mismo framework sin herramientas, con herramientas disponibles y con una petición explícita de usarlas. La guía para medir el uso de contexto de MCP desarrolla esta comprobación.
¿Qué deja sin resolver el experimento?
Trata estos resultados como una primera selección para aplicaciones pequeñas centradas en contenido. Estas cuatro limitaciones deben influir en tu decisión:
- Carga de trabajo: un catálogo con poca interacción no representa un editor complejo, un panel de control o un juego. Los agentes también eligieron la arquitectura de renderizado.
- Tamaño de la muestra: cinco intentos aportan ejemplos y rangos útiles, pero las posiciones cercanas siguen siendo inciertas. Los rangos muestran mínimos y máximos observados, no intervalos de confianza.
- Entorno: se probó un modelo, un agente y un nivel de esfuerzo. Qwik pasó de
1.20.2a1.20.3después de la primera ejecución. La combinación solicitada Gracile+Lit también produjo dos implementaciones sin Lit. - Resultado: las mediciones de carga de página de Lighthouse en modo móvil no cubren toda interacción ni todos los requisitos de producción. Las líneas de código miden tamaño; no validan una predicción del coste de mantenimiento.
También importa la excepción de Angular. El repositorio de resultados registra que los cinco intentos pasaron las pruebas de aceptación, aunque fallaron dos mediciones de producción. En tu experimento, registra por separado las pruebas superadas y el despliegue correcto.
Cómo medir el coste de Claude Code en tu proyecto
Empieza con dos candidatos y tres intentos nuevos por candidato. Amplía a cinco si los resultados son parecidos. Es una propuesta de prueba piloto, no un nuevo resultado del benchmark.
1. Fija la tarea y el estado inicial
Compara una funcionalidad acotada con las mismas comprobaciones de aceptación. En un producto existente, incluye tu framework actual entre los candidatos. Prepara ambos proyectos iniciales antes de medir una modificación; incluye la preparación en ambos si comparas la creación desde cero.
Define una tarea concreta en SPEC.md. Por ejemplo, prepara páginas de catálogo equivalentes y el mismo conjunto de datos de prueba de productos. Después, pide lo siguiente:
Add case-insensitive name search to the catalog.
Read products from the existing fixture.
Persist the search query in the URL across reloads.
Show an accessible empty state when nothing matches.
Keep existing routes and the acceptance tests unchanged.Fija las versiones de las dependencias y conserva los lockfiles. Instala las dependencias antes de probar una modificación y comprueba que ambos proyectos ofrezcan npm run build y npm test. Guarda una copia intacta de las pruebas de aceptación.
En cada repetición, mantén el mismo código inicial, prompt, modelo y nivel de esfuerzo. Mantén también los permisos, las herramientas del framework y la vía de acceso y facturación. Inicia una conversación nueva desde una copia limpia para cada intento. Alterna el orden de los frameworks y registra el uso de caché.
Registra también instrucciones de usuario, hooks y plugins que puedan cambiar el comportamiento. Si prefieres la aplicación original y sus comprobaciones, empieza con el entorno del benchmark de Lawson.
2. Captura una ejecución y su resultado final
Usa Bash con Claude Code autenticado y jq instalado. Comprueba la autenticación con claude auth status --text; si hace falta, ejecuta claude auth login antes de probar.
Ejecuta la prueba en un contenedor de desarrollo desechable. La lista de permisos del ejemplo autoriza automáticamente cambios en archivos y comandos de shell. Autoriza de antemano las llamadas MCP previstas mediante reglas de permisos que se carguen en cada entorno. Conectar un servidor no basta.
Pon un trial_label distinto para cada condición. El ejemplo usa la CLI no interactiva documentada y crea un directorio de salida único.
trial_label=astro-01
trial_dir=$(mktemp -d "/tmp/${trial_label}.XXXXXX") || exit 1
claude --version > "$trial_dir/claude-version.txt"
git rev-parse HEAD > "$trial_dir/commit.txt"
trial_status=0
CLAUDE_CODE_EFFORT_LEVEL=high claude -p \
--model claude-opus-5-5 \
--max-budget-usd 10 \
--allowedTools "Read,Edit,Write,Bash" \
--output-format stream-json --verbose \
"Implement SPEC.md without changing dependencies or acceptance tests. Run npm run build and npm test. Report incomplete work." \
> "$trial_dir/session.jsonl" 2> "$trial_dir/stderr.log" \
|| trial_status=$?
printf '%s\n' "$trial_status" > "$trial_dir/exit-code.txt"
jq -s '
[.[] | select(.type == "result")] | last
| if . == null then error("No final result; record an incomplete run")
else {
session_id,
subtype,
is_error,
estimated_usd: .total_cost_usd,
reported_wall_minutes: (.duration_ms / 60000),
modelUsage,
permission_denials
} end
' "$trial_dir/session.jsonl" > "$trial_dir/summary.json"
cat "$trial_dir/summary.json"
printf 'Results: %s\n' "$trial_dir"El umbral de $10 es una elección para el ejemplo. --max-budget-usd se basa en el gasto API estimado, y el gasto puede superar el umbral. Aplica el mismo umbral a todas las condiciones y registra las paradas por presupuesto.
A fecha de 2026-11-06, CLAUDE_CODE_EFFORT_LEVEL tiene prioridad sobre --effort. Los límites de esfuerzo de la organización pueden seguir restringiendo el nivel elegido. Si el modelo no se carga, resuelve la configuración de Opus 5.5 antes de continuar.
El resumen debe incluir estimated_usd, reported_wall_minutes, modelUsage y los posibles permission_denials. La transcripción JSONL conserva los eventos de herramientas para inspeccionarlos. Confirma que aparece el modelo previsto y registra cualquier modelo adicional utilizado.
3. Compara los resultados aceptados y conserva los fallos
Usa modelUsage para contar los tokens del agente y sus subagentes. Mantén separados inputTokens, outputTokens, cacheReadInputTokens y cacheCreationInputTokens. El campo usage del mensaje de resultado excluye la actividad de los subagentes.
Lee el resultado final una sola vez. No sumes totales acumulados de varios resultados ni reutilices una sesión reanudada como intento nuevo.
Ejecuta por tu cuenta las pruebas sin modificar y la compilación de producción. Comprueba que los archivos de dependencias y pruebas no cambiaron. Que el agente informe de un éxito no demuestra que la aplicación cumpla la especificación.
Si falta el resultado final o su formato no es válido, revisa stderr.log. Registra un intento incompleto con coste desconocido. No introduzcas cero. Resuelve las denegaciones de permisos antes de atribuir al agente la falta de uso de un MCP.
Para cada framework, informa del número de intentos aceptados respecto al total. Añade medianas y rangos de las ejecuciones exitosas y el coste estimado total de todos los intentos. Para obtener el coste por resultado aceptado, divide el coste estimado de todos los intentos entre el número de resultados aceptados:
Total quoted cost of all attempts / Number of accepted results
Si falta el coste de algún intento, marca como incompleto el coste del lote. Sin resultados aceptados, informa del fallo en vez de asignar un coste por resultado. Registra aparte el tiempo de revisión humana.
En sesiones manuales, el informe actual de costes de Claude Code muestra esa misma clase de estimación en /usage. La referencia de comandos incluye /cost como alias a fecha de 2026-11-06. Los límites de uso de la suscripción y los cargos reales del proveedor siguen siendo distintos de esa estimación.
Conserva tu stack si una pequeña reducción de tokens no compensa el trabajo de revisión o migración. Reconsidera la decisión cuando el candidato supere repetidamente las mismas comprobaciones. Su coste total de adopción y mantenimiento también debe ser aceptable.
Después de elegir un framework, prueba otro modelo o vía de acceso en un experimento aparte. La comparativa de modelos para programar puede ayudarte a elegir candidatos sin cambiar varias variables en la prueba de frameworks.
