Busca en todas las páginas de la documentación
Un framework web "ligero" de Node.js —Hono, Koa, Polka y otros similares— se trata menos del tamaño del archivo que de una base diferente: en lugar de envolver los objetos http.IncomingMessage/http.ServerResponse propios de Node, estos frameworks se construyen sobre las clases estándar web Request y Response, las mismas que ya entienden un navegador o un Cloudflare Worker.
Esa única elección se extiende a casi todo lo demás que cubre esta sección.
Es la razón por la que el mismo manejador de rutas puede ejecutarse en Node, en el edge o en Bun con pocos o ningún cambio, por qué el middleware se compone de la manera en que lo hace y por qué estos frameworks tienden a venir con una fracción del árbol de dependencias de Express.
Conceptos básicos de Hono y Koa y Polka muestran el código; esta página es el modelo subyacente: lo que "ligero" realmente te ofrece y lo que cuesta.
Request/Response de la web, lo que los hace portátiles entre tiempos de ejecución y mantiene su núcleo pequeño.http de Node; ese vínculo es invisible hasta que intentas ejecutar el mismo manejador en un lugar que no sea Node, o hasta que el peso de las dependencias comienza a importar para los arranques en frío.Request/Response.http de Node, la API Fetch, entornos de ejecución edge/serverless, tuberías de middleware, compensaciones en la selección de frameworks.Todo framework web de Node tiene que responder primero a una pregunta: ¿cómo se ve una solicitud dentro de un manejador?
Express, Koa (en su forma clásica) y el módulo http sin procesar responden con los objetos nativos de Node: IncomingMessage para la solicitud, ServerResponse para la respuesta, objetos basados en streams que existen solo porque el módulo http de Node es anterior a cualquier estándar web para representar un intercambio HTTP en JavaScript.
Hono responde de manera diferente: un manejador recibe un objeto Request estándar y devuelve un objeto Response estándar, las mismas clases exactas definidas por la API Fetch y ya implementadas en todos los navegadores modernos, en Deno, en Bun y en entornos de ejecución edge como Cloudflare Workers.
Node mismo ha soportado estas clases globales de forma nativa desde la versión 18, por lo que una aplicación Hono que se ejecuta bajo @hono/node-server no está simulando una API de navegador, está usando la misma que el tiempo de ejecución ya proporciona.
Una analogía útil: piensa en Request/Response como un estándar de contenedor de envío.
Antes de los contenedores estandarizados, cada puerto necesitaba su propio equipo de carga especializado para cada tipo de carga; una vez que todos acordaron la forma del contenedor, cualquier grúa en cualquier puerto podía mover cualquier carga, porque el equipo solo necesitaba entender el contenedor, no lo que había dentro.
http.IncomingMessage de Node es una carga con forma para un muelle específico; Request/Response de la API Fetch es el contenedor de envío, y un framework construido alrededor del contenedor, no del muelle, puede moverse a cualquier puerto que también hable contenedores.
// Manejador de Hono: una función simple de un contexto tipo Request a Response
app.get("/users/:id", (c) => {
return c.json({ id: c.req.param("id") }); // c.json() devuelve un Response estándar
});Koa se encuentra en el medio: todavía envuelve los objetos http nativos de Node, pero reemplazó el middleware basado en callbacks de Express con async/await y un único objeto ctx temprano, razón por la cual se agrupa con frameworks ligeros aunque no esté basado en Estándares Web como Hono.
Polka va en la dirección opuesta por completo: mantiene los objetos nativos de Node y simplemente agrega un enrutador rápido y mínimo encima, sacrificando la portabilidad por la huella más pequeña posible específicamente en Node.
La parte de "ligero" que realmente cambia la forma en que escribes código es la composición de middleware, y funciona de la misma manera en Hono, Koa y Express, aunque los objetos subyacentes difieran: el middleware no se ejecuta en una lista plana y secuencial.
Se anida, como capas de una cebolla, porque cada función de middleware recibe una callback next() y decide cuándo, o si, llamarla.
solicitud entrante
├─ middleware de logger (trabajo antes de next())
│ ├─ middleware de auth (trabajo antes de next())
│ │ ├─ manejador de ruta (capa más interna)
│ │ └─ auth: trabajo después de que next() retorna (ej. encabezado de respuesta)
│ └─ logger: trabajo después de que next() retorna (ej. duración del registro)
└─ respuesta saliente
El código registrado antes de await next() se ejecuta al entrar, en orden de registro; el código registrado después de await next() se ejecuta al salir, en orden inverso, razón por la cual un middleware de registro que mide el tiempo de una solicitud tiene que envolver la llamada en next(), no solo registrar una vez al principio.
Este modelo de cebolla es lo que hace que el middleware sea componible: una verificación de autenticación puede cortocircuitar al no llamar nunca a next(), y un middleware de modelado de respuesta puede inspeccionar o reescribir lo que produjo el manejador antes de que llegue al cliente, porque todavía está "dentro" de la llamada cuando next() retorna.
Bajo el capó, la elección de los Estándares Web también cambia cómo una solicitud llega a esa cadena de middleware en primer lugar.
El núcleo de una aplicación Hono no tiene idea de que se está ejecutando en Node en absoluto: @hono/node-server es un adaptador, una fina capa de traducción que escucha en un http.Server real de Node, convierte cada IncomingMessage entrante en un Request estándar, lo entrega a la aplicación Hono y convierte el Response que regresa en lo que necesite el socket de Node.
Ese adaptador es el único código específico de Node en toda la pila; cámbialo por un adaptador de Cloudflare Workers (integrado en la plataforma, no se necesita traducción) o un adaptador de Bun, y el mismo objeto app se ejecuta en otro lugar, sin modificar, porque nunca tocó los objetos de Node para empezar.
"Ligero" es en realidad una abreviatura de dos propiedades separadas que no siempre van juntas: huella pequeña (menos dependencias, menor tamaño de instalación, menos código para analizar y compilar JIT al inicio) y portabilidad en tiempo de ejecución (funciona fuera de Node sin una reescritura).
Polka tiene la primera propiedad sin la segunda: es diminuto, pero está diseñado solo para Node.
Hono tiene ambas, porque la portabilidad es lo que permitió a sus autores mantener el núcleo libre de código específico de Node en primer lugar; un framework que busca los globales Buffer o process de Node dentro de su núcleo no puede ejecutarse sin modificar en un entorno de ejecución edge, por lo que evitarlos es una restricción que también reduce el árbol de dependencias.
La huella se justifica principalmente en el arranque en frío: en una plataforma serverless o edge, una nueva instancia tiene que cargar e inicializar el framework antes de poder manejar su primera solicitud, y cada megabyte de código de dependencia y cada cadena require() síncrona se suma a esa latencia.
Una vez que un proceso de Node está caliente y funcionando de manera constante, sin embargo, la brecha entre Hono y Express se reduce drásticamente: ambos están limitados por E/S por el mismo bucle de eventos, y la sobrecarga propia de ninguno de los frameworks suele ser el cuello de botella en comparación con las llamadas a la base de datos o la serialización.
Esa es la compensación honesta: elige un framework ligero por su portabilidad o por implementaciones sensibles al arranque en frío, no bajo la suposición de que hará que un servicio Node ya caliente sea drásticamente más rápido.
La brecha del ecosistema es el otro costo real: Express tiene más de quince años de middleware, respuestas de Stack Overflow y guías de integración que la comunidad de un framework más pequeño aún no ha acumulado, por lo que los equipos a veces terminan escribiendo pequeños adaptadores o middleware ellos mismos que habrían sido una línea de npm install en Express.
| Enfoque | Fortaleza | Debilidad | Mejor ajuste |
|---|---|---|---|
| Hono (núcleo de Estándares Web) | Se ejecuta sin modificar en Node, Workers, Deno, Bun; núcleo diminuto | Ecosistema de middleware más pequeño que Express | Implementaciones multi-runtime, APIs edge/serverless |
| Koa (async-first, nativo de Node) | Middleware async/await limpio, núcleo mínimo, enorme catálogo de plugins existente | Todavía ligado a los objetos http de Node - sin portabilidad edge | Servicios solo de Node que quieren la madurez del ecosistema de Express con un núcleo más limpio |
| Polka (nativo de Node, sin abstracción) | La sobrecarga más pequeña posible en Node; dependencias casi nulas | Solo de Node, características mínimas integradas (sin análisis de cuerpo incorporado, etc.) | Servicios solo de Node críticos para la latencia con necesidades de enrutamiento simples |
| Express (nativo de Node, con todo incluido) | Enorme ecosistema, el más documentado, el valor predeterminado más seguro | La huella más pesada de los cuatro; no portátil fuera de Node | APIs de Node de propósito general donde la amplitud del ecosistema supera la huella |
Lista de verificación para la selección de frameworks convierte esta comparación en un proceso de decisión concreto; Hono en Node vs Edge cubre las diferencias específicas de tiempo de ejecución que importan una vez que has elegido Hono.
Request/Response que define el navegador, pero aún ejecuta código del lado del servidor con acceso completo a la API de Node a través de su capa adaptadora; no está en un entorno aislado como el JavaScript del navegador.http nativos de Node.next() retorne, al salir, razón por la cual el orden cambia el comportamiento en ambas direcciones.Su núcleo evita depender de objetos específicos de Node (como http.IncomingMessage) y globales solo de Node, construyéndose en su lugar sobre las clases estándar Request/Response. Eso es lo que lo hace pequeño y portátil; las dos propiedades suelen ir juntas, pero no son lo mismo.
Un manejador de Express recibe los objetos nativos req/res de Node y muta res directamente; un manejador de Hono recibe un contexto que envuelve un Request estándar y devuelve un objeto Response estándar, coincidiendo con la misma API que usa una llamada Fetch o un Cloudflare Worker.
No, significa que el núcleo de Hono reutiliza las mismas clases Request/Response que define un navegador, por lo que las formas coinciden, pero el código aún se ejecuta del lado del servidor con acceso completo al tiempo de ejecución a través del adaptador (Node, Workers, Bun) que lo esté ejecutando.
Cada middleware envuelve todo lo registrado después de él, por lo que el código antes de await next() se ejecuta al entrar, en orden, y el código después de next() se ejecuta al salir, en orden inverso; mover un middleware antes o después cambia tanto cuándo ve la solicitud como cuándo ve la respuesta.
Un adaptador (@hono/node-server para Node) es la capa de traducción entre los objetos nativos de un tiempo de ejecución y el núcleo de Estándares Web del framework; convierte un IncomingMessage entrante en un Request y convierte el Response devuelto en lo que necesita el socket de Node. Es el único código específico de Node en la pila.
Solo en el eje de la huella: Polka es solo de Node y no utiliza la forma Request/Response de los Estándares Web, por lo que es pequeño pero no portátil a entornos de ejecución edge o no-Node como Hono.
Principalmente en el arranque en frío, donde menos código para cargar e inicializar es lo más importante. Una vez que un proceso está caliente, la sobrecarga del framework rara vez domina en comparación con las llamadas a la base de datos, la serialización y la E/S de red.
Porque su núcleo es inusualmente mínimo para un framework nativo de Node (sin enrutador ni analizador de cuerpo incorporados, middleware async/await primero y una pequeña huella de dependencias), aunque no comparte la portabilidad edge de Hono.
Menos paquetes de middleware preconstruidos y mantenidos por la comunidad, y menos respuestas existentes a problemas comunes; los equipos a veces escriben pequeñas integraciones ellos mismos que ya existirían para Express.
Sí, en Node; el adaptador proporciona a los manejadores acceso completo al tiempo de ejecución de Node. La restricción que mantiene a Hono portátil es que su propio núcleo evita depender de esos globales, no que el código de tu aplicación no pueda usarlos cuando se ejecuta específicamente en Node.
No, es común usar Express o Fastify para un monolito solo de Node y Hono específicamente para servicios que necesitan ejecutarse en una plataforma edge o ser portátiles, eligiendo por servicio según dónde se despliegue realmente ese servicio.
No, el constructor Response estándar acepta un cuerpo ReadableStream, por lo que el streaming funciona de la misma manera conceptual que con los streams de Node, solo que se expresa a través de la API Web Streams en lugar de las clases de stream de Node.
Versiones de la pila: Esta página fue escrita para Node.js 24 LTS, npm 10+ y TypeScript 5.6+.
Revisado por Chris St. John·Última actualización: 15 jul 2026