Hono frente a NestJS: dos plantillas de producción con el mismo contrato y números reales

Ya tienes en el blog mi plantilla de Hono + Prisma para APIs en producción y la de NestJS. Las dos hacen lo mismo: la misma API de tareas con usuarios, el mismo contrato HTTP, el mismo esquema de base de datos con Prisma 7. Y eso es exactamente lo que necesitaba para contestar con datos una pregunta que me hacen mucho: ¿Hono o NestJS?

Ya hice una comparativa de cuatro frameworks (Hono, Fastify, Express y NestJS) con servidores mínimos. Era útil, pero un «hola mundo» no te dice cómo se comporta un framework cuando tiene que servir autenticación con sesiones, 2FA, recuperación de contraseña, rate limiting en base de datos y 25 rutas documentadas. Aquí la comparación es entre dos aplicaciones reales y equivalentes, y además mido por separado el framework solo para no atribuirle a uno lo que en realidad es culpa (o mérito) de otra cosa.

Te adelanto la conclusión que menos esperaba: en las plantillas completas, la de NestJS salió más rápida que la de Hono, aunque el núcleo de Hono rinde casi el doble que el de Nest cuando lo mido a solas. Más abajo verás por qué, qué parte de la explicación está medida y qué parte es solo una hipótesis.

Las dos plantillas, en una tabla

Antes de comparar, conviene dejar claro qué es igual para saber que lo que mido después es la diferencia real y no un efecto de que hagan cosas distintas.

Dos de esas filas las he comprobado de forma mecánica, no a ojo (el 24 de octubre sobre main; las ramas de los PR no tocan prisma/: lo comprobé con un diff contra main, y siguen pasando los 95 escenarios de contrato, pero no volví a descargar el /openapi.json). Primero, descargué el /openapi.json de cada servidor arrancado: los dos documentos tienen 25 rutas y 31 operaciones. Y segundo, hice un diff de los dos schema.prisma:

$ diff prisma/schema.prisma  ../nestjs-prisma-production-starter/prisma/schema.prisma
33a34
>   emailOutbox   EmailOutbox[]
52a54,78
> }
>
> /// Durable outbox for account emails. A request only persists an intent (together with its
> /// audit entry); a worker delivers it with bounded retries, so a crash or an SMTP outage
> ...
$ diff <(ls hono/prisma/migrations) <(ls nest/prisma/migrations)
9a10
> 20261023090922_email_outbox

Las dos plantillas comparten todo el modelo de datos salvo la tabla de la cola de correos (EmailOutbox) y su migración. Esto tiene una consecuencia práctica enorme que retomo en la sección de migración: cambiar de una a otra no toca la base de datos.

La prueba que más me ha sorprendido: el mismo contrato, 95 escenarios, 0 fallos en las dos

El repositorio de NestJS incluye un arnés de pruebas HTTP «de caja negra» (contract/run.mjs) que repite los mismos escenarios contra cualquier servidor que le indiques: no sabe si al otro lado hay Hono, Nest o lo que sea. Se diseñó para comprobar que el port a NestJS se comportaba como la plantilla original de Hono, y lo lancé contra las dos, cada una con su propia base de datos, en los tres modos de autenticación. La salida y los números de abajo son de la segunda pasada (ramas de los PR, 25 de octubre); en la primera, sobre main, el resultado fue el mismo: 95, 76 y 32 escenarios, 0 fallos en las dos.

$ node contract/run.mjs --base http://127.0.0.1:3911 --mode full --db h-full.db   # servidor Hono
  ✓ system (13 tests)      ✓ recovery (11 tests)
  ✓ mounting (6 tests)     ✓ mfa (10 tests)
  ✓ auth (14 tests)        ✓ ratelimit (5 tests)
  ✓ sessions (8 tests)     ✓ ratelimit-login (4 tests)
  ✓ tasks (16 tests)       ✓ users (14 tests)    ✓ audit (5 tests)

contract: 95 tests, 0 failing (26561ms, mode=full)

Esa última columna ya adelanta algo: en el modo sin usuarios (none) los dos tardan lo mismo; en los modos con usuarios, Hono tarda entre 3,7 y 7 veces más. Es el coste de hacer login con bcryptjs, y lo mido de forma directa más abajo.

El arnés también puede volcar una transcripción normalizada de cada petición y respuesta, así que fui un paso más allá y comparé las dos transcripciones, petición a petición (normalizando los UUID de las rutas, que cambian en cada ejecución). Esta comparación es de la primera pasada (24 de octubre, main): no repetí el volcado con las ramas de los PR (sí el arnés, que pasa entero):

En las 710 peticiones, las dos plantillas devuelven el mismo código HTTP. Las diferencias de cuerpo son pocas y de tres tipos: datos que cambian en cada ejecución (correos de prueba aleatorios, códigos de recuperación), textos como el nombre y el título del documento OpenAPI, y tres diferencias reales que me parecen interesantes:

1. La IP. Hono guarda ::ffff:127.0.0.1 (la forma «IPv4 mapeada en IPv6») y Nest guarda 127.0.0.1. No he investigado de dónde sale la diferencia (probablemente de cómo cada servidor lee la dirección del socket). Es cosmético, pero si guardas IP en tus auditorías y mezclas servicios, te toparás con las dos formas.
2. El detalle de las auditorías. En los eventos LOGIN_FAILED y DELETE_PERMANENT, Hono guarda el correo en claro y Nest guarda en su lugar un identificador opaco de 32 caracteres hexadecimales (el correo no aparece):

hono  LOGIN_FAILED     {"email":"[email protected]"}
nest  LOGIN_FAILED     {"account":"f2a17a4412b0499d02ea85eec653d736"}
hono  DELETE_PERMANENT {"email":"[email protected]"}
nest  DELETE_PERMANENT {"account":"1d1c5b45504c9441edd640fa292cd5e3"}

Es una decisión de privacidad (que el registro de auditoría no guarde correos de personas) que solo toma la plantilla de Nest. 3. Un error 400. Para un cuerpo mal formado en el login, Hono responde Malformed JSON in request body y Nest Validation error in request payload (con una lista errors por campo). El código es el mismo, el texto no.

Dos filosofías: composición de funciones o estructura impuesta

Las diferencias de fondo vienen de aquí, y casi todo lo demás es consecuencia.

Hono parte de la idea de que una aplicación web es una función: recibe una Request estándar (la misma de fetch) y devuelve una Response. Alrededor de esa función se encadenan middlewares con app.use(...), y las rutas se registran con métodos como app.get. No hay contenedor de dependencias, no hay decoradores, no hay módulos: importas lo que necesitas y lo usas. Lo cuento en detalle en Hono a fondo.

NestJS parte de la idea contraria: una aplicación grande necesita estructura para que muchas personas la toquen sin pisarse. Por eso te da módulos, controladores, proveedores con inyección de dependencias, guards, pipes, interceptores y filtros, cada uno con su sitio y su orden de ejecución. Lo cuento en NestJS 12 a fondo y, aplicado a esta plantilla, en su artículo.

Mejor que describirlo es verlo. Esta es la misma ruta (crear una tarea) en las dos plantillas, con el código real de cada repositorio:

// Hono · src/routes/tasks.ts
const createTaskRoute = createRoute({
  method: "post",
  path: "/",
  tags: ["Tasks"],
  summary: "Crear tarea",
  security,
  request: jsonBody(createTaskSchema),
  responses: {
    201: jsonResponse(successSchema(taskSchema), "Tarea creada"),
    ...errorResponses({ 400: "Error de validación", ...authErrors }),
  },
});

// … y más abajo, encadenada al router:
.openapi(createTaskRoute, async (c) => {
  const { title, description, completed } = c.req.valid("json");
  const { userId } = viewerOf(c);

  const newTask = await prisma.task.create({
    data: { userId, title, description, completed },
  });

  await recordAudit(c, { userId, action: "CREATE", entity: "Task",
    entityId: newTask.id, details: { title: newTask.title } });

  return successResponse(c, newTask, { status: 201, message: "Task created successfully." });
});

// NestJS · src/tasks/tasks.controller.ts
@Post()
@ApiOperation({ summary: "Crear tarea", description: "…" })
@ApiCreatedResponse({ description: "Tarea creada" })
@ApiBadRequestResponse({ description: "Error de validación" })
@ApiUnauthorizedResponse({ description: "Token ausente, inválido o sesión revocada" })
async create(@Body() dto: CreateTaskRequest, @Req() req: Request) {
  const { title, description, completed } = dto;
  const { userId } = this.viewerOf(req);

  const newTask = await this.prisma.task.create({
    data: { userId, title, description, completed },
  });

  await this.audit.record(req, { userId, action: "CREATE", entity: "Task",
    entityId: newTask.id, details: { title: newTask.title } });

  return { message: "Task created successfully.", data: newTask };
}

// src/tasks/dto/task.dtos.ts (7 líneas)
export class CreateTaskRequest extends createZodDto(createTaskSchema) {}

El cuerpo del handler es casi idéntico: prisma.task.create, auditoría, respuesta. Lo que cambia es el cableado a su alrededor, y eso es lo que resume este diagrama:

Hay tres diferencias que se ven en el código:

1. Dónde vive el esquema. En Hono, la propia ruta declara el esquema de la petición y el de cada respuesta (successSchema(taskSchema)), y de ahí salen la validación, los tipos de c.req.valid("json") y el OpenAPI. En Nest, el esquema de la petición se convierte en una clase (createZodDto) para que el @Body() la reconozca, pero las respuestas se describen con decoradores (@ApiCreatedResponse({ description })) que, en esta plantilla, llevan solo una descripción de texto, no un esquema.
2. Cómo llega Prisma al código. En Hono, prisma es un módulo que se importa. En Nest, PrismaService es un proveedor que el contenedor entrega por constructor.
3. Cuánto ocupa la ruta. tasks.ts de Hono tiene 443 líneas (seis rutas con sus esquemas de documentación y sus handlers); el controlador de Nest tiene 400, más 7 de DTO y 11 del módulo (tasks.module.ts). Prácticamente empate; no hay un framework que te ahorre código de forma significativa en este recurso.

Inyección de dependencias frente a importar módulos

Esta es la diferencia que más pesa en el día a día y la que más se discute. Dejo los hechos antes que mi opinión.

En Hono no hay contenedor. Un servicio es una función o un módulo que importas:

import { prisma } from "../db.js";
import { recordAudit } from "../lib/audit.js";

Es simple, sin magia, y se sigue con «ir a la definición». El coste: las dependencias están cableadas por import. Si quieres sustituir prisma en una prueba, necesitas sustituir el módulo (con vi.mock) o, como hace esta plantilla, no sustituirlo: sus pruebas no tienen ningún vi.mock; usan una base de datos SQLite temporal real (con las migraciones aplicadas) y llaman a la aplicación en memoria con app.request("/api/tasks", …), sin abrir ningún puerto.

En Nest, cada clase declara lo que necesita en el constructor y el contenedor lo entrega:

@Controller("api/tasks")
export class TasksController {
  constructor(
    private readonly prisma: PrismaService,
    private readonly audit: AuditService,
    @Inject(APP_FEATURES) private readonly features: Features,
  ) {}

Lo bueno: las dependencias son explícitas, se pueden reemplazar en las pruebas (Test.createTestingModule({ providers: […] }); esta plantilla no lo necesita: ninguna de sus pruebas sustituye un proveedor) y el módulo documenta qué usa cada cosa. Lo malo: más ceremonia, un concepto más que aprender (proveedores, ámbitos, tokens de inyección) y errores de configuración que solo aparecen al arrancar (Nest can't resolve dependencies of…).

Mi lectura, sin rodeos: la DI de Nest merece la pena cuando hay mucha gente y muchos módulos; en una API de un puñado de recursos es sobre todo ceremonia. La plantilla de Nest lo demuestra: 76 archivos para lo que Hono resuelve en 36, con el mismo contrato (75 y 35 en main). Y a la vez, esos 75 archivos son más fáciles de repartir entre cinco personas que un index.ts con la cadena de middlewares de otro. No hay respuesta universal.

Validación y OpenAPI: una declaración o dos

Las dos plantillas validan con Zod 4 y publican su documentación con Scalar (en /docs) sobre un /openapi.json. La diferencia está en cómo llegan ahí.

Lo que más me gusta de Hono aquí es que el OpenAPI no puede mentir sobre la entrada: la ruta que valida es la misma que se documenta, porque es el mismo objeto. En Nest, la validación (el pipe con Zod) y la documentación (los decoradores de Swagger) son dos cosas que hay que mantener en paralelo; si cambias una y olvidas la otra, el documento queda desfasado sin que nada falle.

Y la ventaja que no tiene equivalente directo en Nest es el cliente tipado: como AppType lleva los esquemas de todas las rutas, un front en TypeScript puede llamar a la API con autocompletado y comprobación de tipos, sin generar código:

// En el front (idea; la plantilla exporta AppType y lo vigila con tests/rpc.test.ts)
import { hc } from "hono/client";
import type { AppType } from "api/src/index";

const client = hc<AppType>("https://api.ejemplo.com");
const res = await client.api.tasks.$post({ json: { title: "Comprar pan" } });

Con Nest, la alternativa habitual es generar un cliente a partir del /openapi.json con herramientas externas. Funciona, pero como las respuestas en esta plantilla solo llevan descripción y no esquema, los tipos de salida de ese cliente generado serían pobres. No lo he probado: es una consecuencia de lo que contiene el documento, no una medida.

Seguridad y autenticación: lo que comparten y lo que no

El arnés de contrato de antes cubre, en los dos servidores, el registro y el login, las sesiones revocables, la propiedad de las tareas (una tarea ajena responde como si no existiera), el CRUD de usuarios con roles, la auditoría, la recuperación de contraseña, el 2FA con TOTP y el rate limiting. Que pasen los mismos 95 escenarios es la mejor prueba de paridad que he podido hacer.

Las diferencias que sí encontré, leyendo el código y ejecutándolo:

Dos matices importantes sobre esa tabla:

• El hash es, con diferencia, lo que más separa a las dos plantillas en tiempo de ejecución, y no es culpa de ningún framework: bcryptjs está escrito en JavaScript puro, así que el cálculo gasta CPU del propio hilo de Node (la plantilla usa la versión asíncrona, que reparte el trabajo en trozos, pero el tiempo sigue siendo el de ese mismo hilo); Argon2id va en un módulo nativo. Cualquier plantilla de Hono podría usar Argon2 y cualquier de Nest, bcrypt. Lo cuento en la sección de medidas porque cambia por completo la lectura de los números.
• El enfoque de autenticación es distinto en filosofía: en Hono, proteges lo que enumeras (cuatro prefijos); en Nest, el guard global protege todo y marcas lo público con @Public(). El primero es más fácil de leer; el segundo falla en el lado seguro si olvidas algo. Con el arnés comprobé que las dos devuelven 401 donde toca; no he intentado forzar un olvido en ninguna.

Pruebas: dos enfoques y un tiempo muy distinto

# NestJS (rama del PR #8)
Test Suites: 13 passed, 13 total
Tests:       84 passed, 84 total
Time:        11.792 s

# Hono (rama del PR #23)
 Test Files  18 passed (18)
      Tests  148 passed (148)
   Duration  81.84s (tests 94%, import 5%, transform 1%)

No son comparables en número: la plantilla de Hono tiene casi el doble de pruebas (148 frente a 84), pero esas cifras dependen de cómo cuente cada autor (una prueba que comprueba muchas cosas cuenta como una). Lo que sí cuenta es lo que cubren, y eso lo da el arnés de contrato compartido.

Lo más llamativo es el tiempo. Pasé la suite de Hono con el informe en JSON para ver qué archivos tardan (medido el 24 de octubre sobre main; no repetí este desglose con la rama del PR, pero la suma total sigue en torno a los 80 s):

account-security.test.ts      28.7 s  (26 pruebas)
users.test.ts                 13.7 s  (13)
security.test.ts               8.8 s  (18)
hardening.test.ts              6.3 s  (8)
account-security-hardening     5.7 s  (9)
health.test.ts                 0.01 s (4)

Los archivos lentos parecen ser los que más usuarios y sesiones crean (no he contado las llamadas una a una). Es coherente con la hipótesis del hash (cada bcryptjs de 12 rondas ronda los 280–290 ms que medí en el login), pero no lo he demostrado, por ejemplo, cambiando el número de rondas en las pruebas.

Una diferencia de enfoque que me gusta: Hono prueba sin abrir puertos (app.request llama directamente a la función), de modo que no hay problemas de puertos ocupados. Nest levanta un servidor real con supertest, que es más fiel al despliegue pero más lento de arrancar. En la práctica, con estas dos suites, la diferencia de tiempo (82 s frente a 12 s) no la explica eso, sino, con toda probabilidad, el hash (hipótesis).

Rendimiento: dos pruebas distintas para no engañarnos

Aquí está el riesgo de este tipo de artículos: medir la plantilla completa y concluir «el framework X es más rápido». Para evitarlo hice dos pruebas con el mismo método:

1. El framework solo (hello world): un servidor mínimo por framework que responde GET / con un JSON fijo. Hono con @hono/node-server, Express 5.3.0 y NestJS 12.2.0 (un controlador, sin Prisma ni auth).
2. La plantilla completa: cada plantilla compilada (dist/), con su base de datos SQLite fresca, sus middlewares, su autenticación y su Prisma.

Método

• Una máquina Linux de 8 núcleos, Node 24.21.0, generador y servidor en la misma máquina (por eso las cifras son orientativas). La prueba del framework solo es del 24 de octubre y no la repetí: no depende de las plantillas, que es justo lo que cambió. La de las plantillas completas la repetí el 25 de octubre sobre las ramas de los PR (Nest 623e447, Hono fc44204), con el mismo script y el mismo método; entre paréntesis dejo los valores del 24 de octubre sobre main.
• autocannon con 20 conexiones durante 8 segundos, tres rondas. En las plantillas, las rondas se alternan (Nest, Hono, Nest, Hono…) para que, si la máquina compartida se carga a ratos, el ruido afecte a las dos por igual.
• Cada ronda arranca el servidor desde cero con una base de datos nueva (prisma migrate deploy antes de medir), NODE_ENV=development, LOG_LEVEL=error y el límite de intentos de login subido a 1.000 para que el propio rate limiting no distorsione la prueba de carga.
• Mido: tiempo hasta que /healthz responde 200, memoria residente (RSS) 3 s después, el primer login (frío) y la mediana de 8 logins en caliente, peticiones por segundo en GET /healthz y en GET /api/tasks (con token), memoria tras la carga y el tiempo de cierre con SIGTERM.
• En GET /api/tasks, cero respuestas distintas de 2xx en las seis rondas, en las dos pasadas.

$ node bench.mjs nest ../nestjs-prisma-production-starter dist/main.js     # ronda 2 del 25 de octubre
{"name":"nest","startMs":883,"idleMiB":188,"coldLoginMs":148,"warmLoginMedianMs":28,"healthzRps":6011,
 "healthzMs":2.81,"tasksRps":904,"tasksMs":21.59,"tasks2xx":7232,"tasksNon2xx":0,"afterLoadMiB":439}
SIGTERM→exit ms: 43
$ node bench.mjs hono ../hono-prisma-production-starter dist/index.js
{"name":"hono","startMs":642,"idleMiB":153,"coldLoginMs":300,"warmLoginMedianMs":283,"healthzRps":4174,
 "healthzMs":4.3,"tasksRps":742,"tasksMs":26.4,"tasks2xx":5935,"tasksNon2xx":0,"afterLoadMiB":384}
SIGTERM→exit ms: 28

Resultado 1: el framework solo (24 de octubre, no repetido)

El núcleo de Hono rinde entre 1,8 y 1,9 veces lo que Express y Nest en este hello world. Dos comprobaciones de sentido común:

• Coincide con mi comparativa anterior. En la de cuatro frameworks con Node 24, Hono (≈18.000 peticiones por segundo) rendía 1,8 veces lo de Express (≈9.900) y NestJS sobre Express quedaba cerca del 89 % de Express. Aquí: 1,8 veces, y Nest en el 95 % de Express. Las cifras absolutas son distintas (aquella prueba usaba contenedores, 100 conexiones y otras rutas; esta, procesos locales y 20 conexiones), pero las proporciones se repiten.
• autocannon tiene un techo. Con latencias de 0,01–0,06 ms es muy posible que el generador, que es de un solo hilo, esté limitando los números de Hono. Es decir, el 78.000 de Hono es probablemente un mínimo de lo que podría dar con otro generador. No lo he comprobado con otra herramienta.

Resultado 2: las plantillas completas

Antes de interpretar nada, dos advertencias sobre la comparación entre las dos pasadas. Hono casi no cambió (mismas cifras dentro del ruido). Nest sí cambió algo: el /healthz sube de 5.328 a 6.011 peticiones por segundo, el arranque pasa de 761 a 883 ms y el primer login de 56 a 173 ms (la ronda 1 fue la más lenta: 203 ms en frío y 55 ms en el login en caliente, un valor atípico que dejo dentro de la mediana y del rango). No sé atribuir esos cambios: el PR #8 quitó un interceptor global que no hacía nada, quitó cinco dependencias y subió versiones en rango, y cualquiera de esas cosas, o el ruido de una máquina compartida, podría explicar una parte; no lo he medido ni lo he aislado. Lo único que sostengo son las medidas de cada pasada.

Léelo despacio, porque cuenta dos historias que se contradicen:

• En capacidad de servir peticiones, Nest gana en la plantilla: un 50 % más en /healthz (6.011 frente a 3.994) y un 20 % más en /api/tasks (904 frente a 756). En las dos rutas los rangos de las tres rondas no se solapan (en /api/tasks, 876–930 frente a 742–772), pero son solo tres rondas, así que no te atrevas a poner decimales a esas diferencias. En la primera pasada fueron +30 % y +18 %: la dirección se mantiene, el tamaño no es estable.
• En memoria y arranque, Hono gana: 34 MiB menos en reposo (154 frente a 188), unos 240 ms antes de responder (esta vez los rangos no se solapan: 626–677 frente a 882–909; el 24 de octubre sí se solapaban, 600–785 frente a 701–812, así que trátalo como una tendencia) y 55 MiB menos tras la carga (384 frente a 439).

Y, sin embargo, en el hello world el núcleo de Hono es casi el doble de rápido. ¿Cómo puede ser que la plantilla de Hono sea más lenta?

Por qué lo que gana un framework no se ve en la plantilla

Lo que está medido: la plantilla de Hono hace más trabajo por petición que su hello world, igual que la de Nest. El gran cambio entre una prueba y otra (de 78.000 a unas 4.000 peticiones por segundo en Hono) no es el framework: es todo lo demás. /healthz consulta la base de datos para medir la latencia (la respuesta lleva database.latencyMs) y /api/tasks comprueba el token, relee el usuario y la sesión de la base de datos (las dos plantillas lo hacen, con consultas en paralelo) y pagina la lista. En la plantilla, el framework pasa a ser una parte pequeña del tiempo total.

Lo que es una hipótesis (no la he medido): por qué ahí la de Nest sale entre un 20 % y un 50 % por delante. Mis sospechosos son la cadena de middlewares de la plantilla de Hono (requestId, secureHeaders, cors, un logger que construye un mensaje por cada petición (en la prueba el nivel era error, así que no llegaba a escribirlo), prettyJSON y bodyLimit) y la capa de zod-openapi, que construye y valida objetos con Zod en cada ruta. Pero Nest también tiene su cadena (helmet, CORS, guards, pipes, interceptores), y no he hecho un perfil de CPU de ninguna de las dos. Podría ser otra cosa (la forma de acceder a SQLite, el serializador JSON, cómo se pagina). Si quisieras sacar de aquí una conclusión de rendimiento para tu proyecto, la única válida es: en una plantilla equivalente, no hay ventaja de velocidad de Hono; mídelo con tu propio código.

El login: lo único que sí es un abismo, y lo explica el hash

El login en caliente tarda 288 ms en Hono y 33 ms en Nest (el 24 de octubre: 288 y 23 ms), una diferencia de entre 9 y 12 veces. La sospecha era el algoritmo de contraseñas, así que la comprobé aislándolo del framework, con las dos librerías tal y como las usan las plantillas. Lo repetí el 25 de octubre (mediana de 15 repeticiones, en la misma máquina):

$ node hash.mjs
{"bcryptjs12_hash_ms":"277.8","bcryptjs12_verify_ms":"283.8",
 "argon2id_hash_ms":"11.4","argon2id_verify_ms":"7.9",
 "argon_hash_prefix":"$argon2id$v=19$m=19456,t=2,p=1"}

Verificar una contraseña cuesta 284 ms con bcryptjs (12 rondas) y unos 8–10 ms con Argon2id (7,9 ms en esta serie de 15) (la configuración de la plantilla: 19 MiB de memoria, 2 pasadas, 1 hilo). El 24 de octubre medí 264 y 9,5 ms: son medidas sueltas y varían unos milisegundos de un día a otro. Hice además una serie más larga con exactamente los parámetros de la plantilla de Nest (@node-rs/argon2 2.2.2, Argon2id, memoryCost 19 456 KiB, timeCost 2, parallelism 1; bcryptjs 3.0.3 con 12 rondas), 50 llamadas tras 3 de calentamiento: el hash con Argon2id tiene una mediana de 8,3 ms (p90 9,6 ms, máximo 48 ms) y la verificación, 9,9 ms (p90 39,5 ms, máximo 115 ms); bcryptjs, 276 ms por hash y 275 ms por verificación (n = 20). En resumen: entre 8 y 10 ms con Argon2id, con picos ocasionales de decenas de milisegundos (no he identificado su causa; hipótesis: la reserva de 19 MiB en cada llamada y que la máquina es compartida). (El PR #23 citaba ≈51 ms para Argon2id. Los parámetros de aquel script eran los mismos, pero calculaba la media de solo 5 llamadas seguidas, sin calentar, y unos pocos picos de 30–80 ms bastan para arrastrarla: repetido tal cual, ese script dio 46, 26 y 11 ms en tres ejecuciones. El 51 era una media ruidosa, no la cifra típica, y ya he corregido el texto del PR; el ≈278 ms de bcryptjs sí coincide con lo que mido aquí.) Eso explica casi todo el abismo del login (el resto es la consulta a la base de datos y la creación de la sesión) y es la hipótesis más probable de por qué las pruebas de Hono tardan 82 segundos y las de Nest 12 (en los tests no lo he comprobado).

Dos cosas que conviene entender sobre esto:

• No es una ventaja de NestJS. Es una decisión de cada plantilla. Pero tiene consecuencias de verdad: con bcryptjs en un solo hilo de Node, un servidor de Hono con esta configuración puede atender unos 3-4 logins por segundo por proceso (1.000 ms ÷ 284 ms) antes de que el login monopolice la CPU. Es una estimación a partir de la medida, no una prueba de carga de login.
• Más lento no es más seguro ni menos. 12 rondas de bcrypt son una elección razonable; Argon2id con 19 MiB y 2 pasadas es la configuración mínima que recomienda OWASP. Aquí el coste es tiempo de CPU del servidor, no la seguridad: los dos funcionan.

Peso, dependencias y seguridad de la cadena de suministro

Aquí no hay ambigüedad: son medidas de disco y de informes de herramientas. La primera vez las ejecuté sobre los dos repositorios tal cual están en main (con el package-lock.json de cada uno) y las repetí el 25 de octubre sobre las ramas de los PR; la tabla da las cifras de la segunda pasada y, entre paréntesis, las de main.

Dos lecturas honestas:

• La mayor parte del peso es de Prisma, no del framework. @prisma/* y prisma pesan lo mismo en las dos: unos 189 MB en la instalación de producción (en el node_modules completo, du da 167–168 MB para @prisma y 41 MB para prisma en las dos). La diferencia atribuible al framework y a su ecosistema es de unos 40 MB en producción (396 frente a 435 MB; el 24 de octubre, unos 50), no de órdenes de magnitud. El «Hono es diminuto» es cierto para el framework (compárate con los 1,4 MB de node_modules de mi comparativa anterior) y casi irrelevante cuando le añades Prisma.
• Sí hay una diferencia grande en número de paquetes: 812 frente a 359 en el lockfile completo (846 antes de que el PR #8 quitara cinco dependencias que nada importaba). Más paquetes es más superficie que auditar, más actualizaciones y más ruido en los informes de vulnerabilidades. Es el coste del ecosistema de Nest (@nestjs/*, rxjs, reflect-metadata, Jest, ESLint y sus plugins).

npm audit: las dos fallaban; con los PR, ninguna

Ejecuté npm audit el 24 de octubre de 2026 sobre main. Ninguna plantilla pasaba un --audit-level=high:

# Hono, main (salida recortada)
$ npm audit --omit=dev
zod  <4.6.6
Severity: high
Zod can exhaust memory while validating oversized constrained collections - GHSA-mrhx-c7xc-m3w5
...
4 vulnerabilities (3 moderate, 1 high)

# NestJS, main (salida recortada)
$ npm audit --omit=dev
multer  2.0.0 - 2.4.0
Severity: high
multer vulnerable to Denial of Service via a pending asynchronous fileFilter after request teardown - GHSA-q7qp-rjg7-q26m
  @nestjs/platform-express  10.4.18 - 10.4.22 || >=11.1.2
    @nestjs/core  >=12.0.1
3 high severity vulnerabilities

Dos detalles. La de Nest era una sola causa (una dependencia indirecta, multer, que el código de la plantilla no usa: no hay ni un FileInterceptor en src/) repetida en tres paquetes, y npm audit proponía una «solución» con --force que degradaría NestJS a la versión 11, que no es lo que quieres; el overrides es la salida correcta mientras @nestjs/platform-express siga fijando multer 2.4.0. La de Hono eran cuatro causas distintas, todas arreglables subiendo versiones. En la primera versión de este artículo dije que no había probado esa copia del lockfile con la aplicación; ahora sí: con las versiones nuevas, las 148 pruebas de Hono y los 95, 76 y 32 escenarios de contrato pasan.

Docker: imagen, endurecimiento y qué dice Trivy

Construí las dos imágenes con su Dockerfile (Docker 26.1.5, sin caché) y las ejecuté, dos veces: sobre main (24 de octubre) y sobre las ramas de los PR (25 de octubre). La tabla pone «antes → después».

Cuatro avisos metodológicos. (1) Después de los PR, las dos imágenes parten del mismo digest de Node 24, así que la comparación de memoria ya no mezcla versiones de Node (en la primera pasada sí: 20 frente a 25). (2) Las paradas y la memoria son medidas sueltas, no medianas de varias ejecuciones: la parada de Nest pasó de 73 a 156 ms y la de Hono de 99 a 151 ms, y no sé atribuir la diferencia (la propia aplicación sale en unos 40 ms según la prueba de rendimiento). (3) La memoria de Nest en el contenedor subió de 79,4 a 93,8 MiB con docker stats (y a unos 157 MiB de RSS dentro del contenedor, frente a unos 119 MiB de Hono: 160.880 kB y 121.748 kB); no lo atribuyo a nada concreto y no medí con el mismo protocolo exacto. (4) El docker stats de Docker y la memoria residente (RSS) del proceso no miden lo mismo, así que de aquí no saco una conclusión de memoria entre frameworks; la mejor medida de memoria de este artículo es la de la sección de rendimiento (154 frente a 188 MiB en reposo, fuera de Docker).

Trivy

Escaneé las dos imágenes con los mismos filtros que usa el CI de la plantilla de Nest (--severity HIGH,CRITICAL --ignore-unfixed), primero sobre main y luego sobre las ramas de los PR (Trivy 0.76.1 las dos veces):

La diferencia entre las dos plantillas tenía una causa clara y no era el framework: la imagen de Hono conservaba npm (con su tar y compañía, vulnerables) porque partía de node:20-alpine sin quitarlo; la de Nest borraba npm de la imagen final y recompilaba el motor de Prisma. Además, TypeScript 7 (que usa la plantilla de Hono) trae el compilador como binario de Go, y Trivy escanea sus dependencias de Go. Ese binario llegaba a la imagen de producción sin que la plantilla lo pidiera: typescript está en sus dependencias de desarrollo, pero npm también lo instalaba en producción como dependencia peer de Prisma (npm ls typescript --omit=dev lo mostraba colgando de @prisma/client y prisma).

Qué cambió en el PR #23 de Hono: la imagen final ya no lleva npm, corepack, yarn ni typescript (el entrypoint ejecuta la CLI de Prisma con node directamente), parte de Node 24 y se actualizaron zod y el resto. Qué cambió en el PR #8 de Nest: el overrides de multer, y la imagen también deja fuera typescript, corepack y yarn. Ojo con el 0: es el resultado de hoy, con la base de datos de Trivy de hoy, y solo cuenta lo que tiene arreglo publicado (--ignore-unfixed).

Lo que me llevó más tiempo: la imagen de Hono no arrancaba con --read-only (corregido en el PR #23)

El docker-compose.yml de Nest usa un sistema de archivos de solo lectura. En main probé a ejecutar la imagen de Hono igual y falló:

$ sudo docker run --read-only --rm --env-file compose.env hono-starter:lab
(salida recortada)
Error: Could not find schema-engine binary

La causa era el Dockerfile de Hono: instalaba con npm ci --omit=dev --ignore-scripts y no volvía a ejecutar @prisma/engines, así que Prisma se descargaba el motor de migraciones en el primer arranque. Eso exige un node_modules escribible y salida a Internet cuando arranca el contenedor. Sin --read-only funcionaba (lo comprobé), pero tienes un contenedor que descarga binarios al arrancar, que es justo lo que no quieres en producción. El de Nest ya lo resolvía con npm rebuild @prisma/engines en la construcción.

El PR #23 lo arregla de la misma manera: ahora el motor se descarga al construir la imagen (npm rebuild @prisma/engines prisma). Lo comprobé con scripts/docker-smoke.sh, que el PR añade a las dos plantillas: construye la imagen, la ejecuta con --read-only, aplica las migraciones, inicia sesión con el administrador sembrado, espera al HEALTHCHECK y comprueba que corre sin privilegios. En las dos ramas pasa entero. Con el docker-compose.yml nuevo de Hono, el contenedor queda Up (healthy) en 127.0.0.1:3011 y docker inspect confirma ReadonlyRootfs=true, CapDrop=ALL y no-new-privileges.

Dos observaciones sobre la plantilla de Nest, que no eran ventajas, sino descuidos: sus logs salían con colores ANSI por defecto (62 líneas con códigos de escape en mi prueba; 0 con NO_COLOR=1), lo que ensucia los agregadores de logs; y la imagen pesaba 719 MB. El PR #8 los arregla: los logs de producción salen sin colores (0 líneas con secuencias de escape en la imagen del PR) y la imagen baja a 570 MB. Y una tercera, que sale de la misma prueba: el entrypoint de Nest migraba la base de datos antes de validar el entorno (un JWT_SECRET ausente dejaba creada y migrada la base de datos y solo entonces abortaba); el PR #8 invierte el orden y, con un volumen vacío y sin secretos, el volumen se queda vacío.

Portabilidad: el argumento que más se repite, y qué pude comprobar

La afirmación habitual es «Hono corre en todas partes y Nest solo en Node». Es cierta en espíritu, pero con las plantillas de este artículo la realidad es más incómoda. Lo separo en tres cosas.

1. El framework. Hono está construido sobre las APIs web estándar (Request, Response, fetch) y funciona en Cloudflare Workers, Deno, Bun, Node y otros. Esto no lo he medido aquí: lo cuento por su diseño, y lo practiqué en otro sitio. En Cloudflare Workers a fondo y en el tutorial API de tareas serverless con Cloudflare, Hono, D1, R2 y Prisma tienes Hono desplegado en Workers; si te interesan los límites y precios, están en D1, R2 y Workers: gratis o de pago. Ojo: ese tutorial es otra aplicación, pensada para Workers desde el principio; no es esta plantilla.

2. La plantilla de Hono de este artículo. Está escrita para Node: usa @hono/node-server, Prisma sobre SQLite local con @prisma/adapter-libsql y @libsql/client, nodemailer para el correo (SMTP), un proceso largo con un trabajo de limpieza en segundo plano y manejo de señales. Llevarla a Workers no es cambiar un import: habría que revisar la base de datos (D1 en lugar de un archivo SQLite), el envío de correo por SMTP, la tarea en segundo plano y el arranque. No lo he intentado con esta plantilla, y no digo que sea imposible; digo que «Hono corre en Workers» y «esta plantilla corre en Workers» son frases distintas.

3. Lo que sí probé: las dos plantillas, compiladas, en Bun. (Esta prueba es de la primera pasada, sobre main; el resultado después del PR #23 está más abajo.) Tenía Bun 1.4.2 en la máquina, así que ejecuté bun dist/… en lugar de node dist/… con el mismo entorno y las mismas pruebas de contrato que usé en la sección de validación (95 pruebas por HTTP, modo full):

$ bun dist/main.js          # NestJS
healthz 200   login 200
contract: 95 tests, 0 failing (6957ms, mode=full)

$ bun dist/index.js         # Hono, tal cual está en el repositorio
error: Failed to start server. Is port 3941 in use?
   code: "EADDRINUSE"
Bun v1.4.2 (Linux x64)

Resultado, y es lo contrario de lo que esperaba:

• La plantilla de NestJS pasó las 95 pruebas en Bun, sin tocar nada.
• La plantilla de Hono, tal cual, se cae al arrancar en Bun. La causa es concreta: el archivo de entrada hace export default app y además levanta su propio servidor con @hono/node-server. Bun, cuando ve un export default con un método fetch, arranca un servidor por su cuenta en el mismo puerto, y ese segundo servidor falla con EADDRINUSE. En Node no pasa porque Node ignora ese export default. Es un caso en que el diseño «portable» de Hono choca con su propia plantilla.

Quise ver si era solo eso. En una copia del dist/ (el repositorio no lo toqué) cambié export default app; por export { app }; y repetí:

$ bun dist/index.js         # Hono, copia con el export cambiado
healthz 200   login 200
contract: 95 tests, 3 failing (25950ms, mode=full)
  ✗ [ratelimit-login] 5 failed logins lock the account; the 6th → 429 with Retry-After
  ✗ [ratelimit-login] the lockout is scoped to the account, not the IP
  ✗ [ratelimit-login] per-IP login limiter (10/min) ends the flood with a 429

Con ese cambio, arranca y pasa 92 de 95. Las tres que fallan son las de ráfagas de logins en paralelo del límite de intentos (los tres errores son «fetch failed», es decir, conexiones que se cortan, o no se llegó a ver el 429 esperado). Las mismas pruebas, con el mismo entorno, pasan 95 de 95 con Node (lo repetí para descartar que fuera el entorno). Si lanzo los intentos de login uno a uno con curl contra el servidor en Bun, el bloqueo funciona (cinco 401 y luego 429), así que el fallo aparece con peticiones concurrentes. No investigué la causa: no sé si es de Bun, de @hono/node-server, de bcryptjs o de la plantilla.

Qué cambió con el PR #23 (25 de octubre). El PR separa la aplicación (src/app.ts) del arranque del proceso (src/index.ts), de modo que ya no hay un export default app junto a un serve(); los tests importan app.ts. Con esa rama, bun src/index.ts arranca con un único servidor y sin retoques (en la fase de correcciones lo lancé desde el código fuente, no desde dist/). El arnés de contrato en modo full contra ese servidor en Bun dio 92 de 95: fallan las mismas tres pruebas de ratelimit-login que ya fallaban en mi copia retocada de main (fetch failed en el primero, y en el segundo un 200 donde se esperaba el 429). Con Node, las mismas 95 pasan. Sigo sin saber la causa y no la he reproducido con peticiones sueltas, así que no te digo que sea de Bun, de la plantilla o de otra cosa. La de Nest en Bun (95 de 95) no la repetí con la rama del PR #8.

¿Y NestJS en Workers o Deno?

Sin probar. Mi hipótesis, y solo eso, es que Nest se lleva peor con los entornos que no son Node: se apoya en decoradores con metadatos (reflect-metadata), en el contenedor de inyección que se construye al arrancar, y la plantilla en @nestjs/platform-express, que es Express, que es Node. Hay adaptadores y gente que lo hace, pero no lo he comprobado en esta plantilla. Si tu destino es Workers, la ruta más corta es Hono, y a eso sí te puedo remitir a los artículos de arriba.

Experiencia de desarrollo, curva de aprendizaje y ecosistema

Esta sección mezcla datos con opinión, así que voy a decirte en cada párrafo cuál es cuál.

Lo que se puede contar (datos)

Las descargas y las estrellas no miden calidad ni adopción en empresas: las descargas incluyen instalaciones de integración continua y dependencias transitivas (no he descontado nada), y las estrellas miden popularidad en GitHub, no uso en producción. Lo único que me permiten decir con seguridad es que ninguno de los dos es un proyecto marginal, y que en 2026 Hono ya se descarga más que NestJS (con la advertencia de que parte de esas descargas pueden venir de otras herramientas que lo instalan por debajo; eso no lo he verificado).

Una cifra que sí me importa para el día a día: la plantilla de Hono tiene menos de la mitad de archivos que la de Nest (36 frente a 76) haciendo lo mismo, y buena parte de esa diferencia es estructura: la plantilla de Nest tiene (contados por nombre de archivo, el 24 de octubre en main) 14 módulos, 10 controladores, 15 servicios y 3 guards, que en Hono son funciones dentro de los archivos de rutas y de utilidades. No he contado cuántos de esos archivos son «solo cableado» ni repetí este recuento con el PR.

Lo que viví construyéndolas (opinión)

• Hono se aprende en una tarde; Nest, en semanas. Hono tiene tres ideas: el contexto c, el middleware con next() y el enrutador. Nest te pide aprender módulos, proveedores, inyección de dependencias, decoradores, guards, pipes, interceptors y filtros, y entender el orden en que se ejecutan. Cada pieza es razonable, pero son muchas. No lo he medido con nadie: es mi experiencia y mi opinión.
• Pero esa estructura es exactamente lo que se aprecia en un equipo grande. En Nest, la pregunta «¿dónde pongo esto?» tiene casi siempre una única respuesta, y eso reduce las discusiones en las revisiones de código. En Hono, la plantilla impone la estructura por convención, no el framework: si alguien no la respeta, nada se queja. Es una ventaja y un riesgo a la vez.
• Las pruebas de Hono son más directas. Los tests llaman a app.request() (lo usan 18 archivos de tests/ y src/) y no necesitan levantar un contenedor de inyección ni sustituir proveedores. Al mismo tiempo, mis 84 pruebas de Nest corren en unos 12 s y las 148 de Hono en unos 82 s (en main, 62 en 8–9 s y 144 en unos 80 s; y esa diferencia, como vimos, no es del framework: es el coste del hash en JavaScript puro, que sospecho que se paga en los tests, aunque no he cambiado las rondas de bcrypt para comprobarlo).
• La inferencia de tipos de extremo a extremo de Hono es muy atractiva, pero no la he probado en un frontend real. La plantilla exporta AppType, que es lo que alimenta hc<AppType> (el cliente tipado de Hono). No he escrito un frontend con él para esta comparativa, así que no te cuento cómo se siente. En Nest, lo equivalente es generar un cliente a partir del OpenAPI (herramientas externas); tampoco lo he probado aquí.
• El ecosistema de Nest es más «de oficina»: módulos oficiales para colas, cron, GraphQL, microservicios, WebSockets, CQRS, y una documentación enorme. En esta comparativa no usé ninguno de esos módulos (la plantilla es una API REST), así que no puedo decirte cuánto valen. Hono tiene un ecosistema de middlewares oficiales y de terceros más ligero, y para cosas como colas o WebSockets tendrás que decidir más piezas tú.
• Los números de «Hono es más rápido» no cambian el día a día de casi nadie. En la plantilla de Nest, a 20 conexiones, /api/tasks sirvió ≈900 peticiones por segundo, y la de Hono entre ≈750 y ≈770. Para una API de una startup, el cuello de botella va a ser la base de datos, el hash de contraseñas o la red mucho antes que el framework.

Mantener a lo largo del tiempo

Un dato que sí pude ver: el 24 de octubre las dos plantillas arrastraban avisos de seguridad (sección de npm audit), y ninguno era del código propio. En Nest, una dependencia transitiva (multer) afectaba a tres paquetes de Nest; en Hono, cuatro paquetes distintos, uno de ellos, zod, es una dependencia directa de la plantilla (y era el de gravedad alta). En ambos casos se arreglaba subiendo versiones, y con los PR las dos están en 0 hoy. Con 812 paquetes en el lockfile de Nest frente a 359 en el de Hono, Nest te dará más avisos que mirar a largo plazo, aunque cada uno sea pequeño. Es una consecuencia directa del tamaño del ecosistema, y eso también incluye herramientas de análisis, pruebas y lint que no van a producción. Los dos PR añaden o mantienen un Dependabot (npm, imagen base y Actions) para que los avisos lleguen solos.

Cuándo elegir cada uno

La tabla resume la comparación. La columna «Base» te dice de dónde sale cada veredicto: medido es algo que ejecuté en esta máquina; diseño es lo que se deduce de cómo están construidos; opinión es mía.

Mi recomendación

• Elige Hono si lo vas a desplegar en el borde (Workers) o quieres poder moverlo entre entornos; si tu API es pequeña o es un servicio concreto, y sobre todo si trabajas solo o con un equipo pequeño que ya conoce TypeScript y prefiere funciones a clases. Con los avisos de arriba: en main la plantilla necesitaba endurecer el Docker (el PR #23 lo hizo y ya está fusionado).
• Elige NestJS si el equipo es grande o va a rotar, o si ya viene de Angular, Spring o .NET y la estructura impuesta le resulta natural; si necesitas módulos oficiales (colas, cron, GraphQL, microservicios) o si valoras que cada cosa tenga un sitio. Ten en cuenta el coste: más ceremonia, más dependencias (812 paquetes en el lockfile) y más superficie de actualizaciones.
• No elijas por el benchmark del hello world. En mis plantillas, con la misma lógica, salió mejor Nest; y aun así no creo que sea un motivo para elegirlo. Lo que decide es el equipo, el destino de despliegue y cuánta estructura quieres que te imponga el framework.

Migrar de uno a otro: lo que probé

Como las dos plantillas comparten esquema de Prisma y contrato HTTP, probé las dos direcciones sobre una base de datos real (no un diagrama). Esta prueba es de la primera pasada (24 de octubre, main). No la repetí con las ramas de los PR; sí comprobé con un diff que ninguno de los dos PR toca prisma/ (ni el esquema ni las migraciones), y que el PR #23 no cambia el hash de las contraseñas, así que no tengo motivo para pensar que el resultado cambie, pero no lo he ejecutado.

De Hono a NestJS (la dirección fácil):

1. Creé la base con la plantilla de Hono (prisma migrate deploy, 9 migraciones) y la dejé con sus datos de ejemplo.
2. Ejecuté prisma migrate deploy con el repositorio de Nest sobre esa misma base: aplicó una sola migración (20261023090922_email_outbox, la tabla de la cola de correos) y la plantilla de Nest arrancó con los datos.
3. Las contraseñas de Hono son bcryptjs ($2b$12$…) y Nest guarda Argon2id. Nest sabe verificar las dos y migra de forma progresiva: tras un inicio de sesión correcto del usuario [email protected], su hash pasó de $2b$12$… (60 caracteres) a $argon2id$v=19$m=19456… (97 caracteres).

$ node q.mjs migra.db            # antes del login de ana, con la base creada por Hono
[email protected]  $argon2id$v=19$m=194…  (97)
[email protected]  $2b$12$nUxHabdYJzjOt…  (60)

$ curl -X POST …/api/auth/login -d '{"email":"[email protected]","password":"…"}'
login ana (bcrypt de Hono) -> 200

$ node q.mjs t.db                # después del login, en una copia de la base
[email protected]  $argon2id$v=19$m=194…  (97)
[email protected]  $argon2id$v=19$m=194…  (97)

(El usuario admin aparece ya en Argon2id antes del login. No investigué por qué; mi sospecha, sin comprobar, es que la siembra de Nest reescribe la cuenta del administrador al arrancar. No cambia la conclusión sobre ana.)

De NestJS a Hono (la dirección incómoda): la base ya tiene aplicada la migración de la cola de correos, y Hono no conoce esa migración. La plantilla de Hono se niega a arrancar, y lo hace bien:

$ node dist/index.js        # Hono sobre la base que ya usó Nest
FATAL: ❌ Database migration history does not match prisma/migrations. Resolve it before starting the server.
  "message": "Migration history does not match prisma/migrations:\n  Applied but absent from prisma/migrations: 20261023090922_email_outbox — the migration files were deleted or renamed"

Es un buen comportamiento (falla pronto y con un mensaje claro en lugar de trabajar con un esquema que no conoce). Pero implica trabajo manual: llevar la migración y el modelo EmailOutbox a Hono, o borrar la tabla. Y hay un segundo obstáculo que no he ejecutado, solo leído en el código: tras unos cuantos inicios de sesión en Nest, parte de los usuarios tendrán hashes Argon2id, y la plantilla de Hono verifica solo con bcryptjs y no incluye Argon2. Lo esperable es que esos usuarios no puedan entrar hasta que restablezcan la contraseña. Es una inferencia, no un resultado.

Lo que no he podido comprobar

Prefiero que lo veas tú aquí que descubrirlo después:

• Por qué la plantilla de Nest sirve más peticiones que la de Hono. Mi hipótesis es que la pila de la plantilla (los middlewares, el registro de peticiones y la validación) cuesta más en Hono que lo que cuesta el contenedor de Nest. No perfilé ninguna de las dos, y el hello world demuestra lo contrario para el framework solo.
• Que bcrypt sea la causa de que los tests de Hono tarden 82 s. Es coherente con el micro-benchmark del hash (284 ms frente a 7,9–9,9 ms por verificación el 25 de octubre; 264 y 9,5 el 24), pero no cambié las rondas de bcrypt en los tests. Hubo además una pasada con 32 fallos que no he podido reproducir ni explicar (las tres siguientes pasaron limpias). Aparte, 3 fallos que sí fueron culpa mía: variables de entorno que se me habían quedado exportadas.
• El techo de autocannon. Con un generador de un solo hilo, las 78.000 peticiones por segundo de Hono pueden ser un mínimo.
• La plantilla de Hono en Workers o Deno, y la de Nest en Deno y Workers. Solo probé Bun.
• hc<AppType> en un frontend real, y la generación de clientes desde el OpenAPI de Nest.
• La memoria en el contenedor. docker stats y la memoria residente no miden lo mismo, y son medidas sueltas; la de Nest subió con el PR (79,4 → 93,8 MiB) sin que sepa por qué. Con los PR, las dos imágenes sí usan ya el mismo Node 24.
• Un SBOM, Coolify, SMTP real, Turso o varias instancias. Nada de eso está en esta prueba.
• La causa de que 3 pruebas de ráfagas de login fallen en Bun con Hono (siguen fallando con el PR #23), y la razón de que el admin aparezca ya en Argon2id en la prueba de migración.
• Mi lista de descargas no descuenta instalaciones transitivas.
• La CI de GitHub con los cambios de los PR. Los pasos los ejecuté en local (construcción, docker-smoke.sh, Trivy 0.76.1, arnés de contrato, pruebas con cobertura), pero ningún flujo de GitHub Actions ha corrido con ellos, y el cambio de CI de Hono ni siquiera está en el PR (el token no tenía permiso para tocar workflows).
• Lo que no repetí tras los PR: el volcado petición a petición del contrato, la prueba de migración entre plantillas, Bun con la plantilla de Nest, el rendimiento del framework solo, Bruno y test-api.sh en Nest, y los experimentos de mutaciones (solo repetí el M8 de Nest). Esas cifras son del 24 de octubre sobre main.
• Argon2 en la plantilla de Hono. El PR #23 lo deja como seguimiento y no lo he implementado ni medido en la propia plantilla.
• Los trade-offs de diseño que no toqué en ninguna de las dos: el bloqueo de cuenta permite dejar fuera durante 15 minutos a un usuario cuyo correo conozcas (denegación de servicio dirigida); el registro revela si un correo ya existe (enumeración de usuarios); y la cobertura del rate limit hay que revisarla ruta a ruta. Los dos PR los señalan y los dejan a decisión del dueño. Los he comprobado en la plantilla de Nest (su artículo los detalla); en la de Hono los traslada su descripción del PR, y no los he vuelto a ejecutar aquí.

Lo que corregí en mis propias plantillas, y lo que queda

Esto es lo que encontré midiendo, lo que ya está corregido (en los PR, ya fusionados) y lo que queda:

1. NestJS (PR #8): hecho: overrides de multer (npm audit y Trivy a 0), cinco dependencias sin uso fuera, logs sin colores ANSI en producción, validar el entorno antes de migrar en el entrypoint, imagen de 719 a 570 MB y 22 pruebas nuevas (84). Queda: logs en JSON, una prueba de concurrencia que distinga el código atómico en SQLite, los cambios de CI y los trade-offs de diseño de arriba.
2. Hono (PR #23): hecho: dependencias subidas (npm audit de 9 a 0), motor de Prisma precompilado en la imagen (ya arranca con --read-only), npm, corepack, yarn y typescript fuera de la imagen final (Trivy de 38 a 0), compose endurecido y publicado en 127.0.0.1, scripts/docker-smoke.sh, Dependabot y 4 pruebas nuevas (148). Queda: Trivy y el resto del cambio de CI (preparado como parche, no subido), Argon2, el auto-baseline del entrypoint y los trade-offs de diseño.
3. Node: hecho en las dos: imagen en node:24-alpine fijada por digest (Hono estaba en Node 20, por debajo de su propio engines ≥ 22.12; Nest, en la 25, sin LTS). Cuando salga la siguiente LTS habrá que cambiar el digest (Dependabot propone el bump).
4. Hono, para Bun: hecho: app.ts separado de index.ts. Queda por entender el 92 de 95.
5. Un cambio de comportamiento que debes conocer: el docker-compose.yml de Hono ahora publica 127.0.0.1:3011 y no todas las interfaces; pon un proxy inverso delante (como ya recomienda su README) o cambia el mapeo de puertos.

Conclusión

Si me preguntas cuál es «mejor», la honesta es que no hay uno. Con la misma API, el mismo esquema de datos y el mismo contrato, los dos hacen el trabajo y las diferencias de verdad están en otro sitio:

• El framework solo: Hono es mucho más ligero y más rápido (1,8–1,9 veces), pero eso apenas se nota cuando le pones encima Prisma, validación y una API con autenticación. En mi plantilla completa, Nest sirvió más peticiones, en las dos pasadas (+20 % a +50 % en la segunda).
• El hash de contraseñas: la diferencia más grande de mis medidas (288 ms frente a 33 ms por login) no es de ningún framework; es una decisión de la plantilla. Mira ahí antes de culpar a nadie.
• El peso y la superficie de actualizaciones: Hono gana por un margen razonable (unos 40 MB y menos de la mitad de paquetes), pero lo que más pesa es Prisma en los dos.
• Lo que fallaba en las dos plantillas era de las plantillas, no de los frameworks: avisos de dependencias, una imagen con npm dentro, una versión de Node sin soporte o sin LTS. Lo corregí en los dos PR (ya fusionados), y con ellos las dos pasan npm audit y Trivy con 0 hoy, con 547 y 570 MB de imagen.
• La estructura y el equipo: Nest te impone una forma de trabajar; Hono te deja libertad y te exige disciplina. Esa es la decisión real, y los números de rendimiento no la contestan.

Si quieres seguir leyendo: las plantillas, hono-prisma-production-starter y nestjs-prisma-production-starter tienen cada una su artículo; el detalle de cada framework está en Hono a fondo, Express a fondo, Fastify a fondo y NestJS 12 a fondo; la comparativa con servidores mínimos es Hono, Fastify, Express y NestJS: comparativa. Si despliegas Hono en el borde, empieza por Cloudflare Workers a fondo y el tutorial de la API de tareas serverless; para exponer una API desde casa o un servidor, Cloudflare Tunnel a fondo, WAF y DDoS en Cloudflare y Coolify, el PaaS autoalojado.