Search across all documentation pages
A "lightweight" Node.js web framework - Hono, Koa, Polka, and others like them - is less about file size than about a different foundation: instead of wrapping Node's own http.IncomingMessage/http.ServerResponse objects, these frameworks build on the Web Standard Request and Response classes, the same ones a browser or a Cloudflare Worker already speaks.
That single choice cascades into almost everything else this section covers.
It's why the same route handler can run on Node, on the edge, or on Bun with little or no change, why middleware composes the way it does, and why these frameworks tend to ship with a fraction of Express's dependency tree.
Hono Basics and Koa & Polka show the code; this page is the model underneath it - what "lightweight" actually buys you, and what it costs.
Request/Response API, which is what makes them portable across runtimes and keeps their core small.http module; that tie is invisible until you try to run the same handler somewhere that isn't Node, or until dependency weight starts to matter for cold starts.Request/Response shape.http module, the Fetch API, edge/serverless runtimes, middleware pipelines, framework selection trade-offs.Every Node web framework has to answer one question first: what does a request look like inside a handler?
Express, Koa (in its classic form), and the raw http module all answer with Node's native objects - IncomingMessage for the request, ServerResponse for the reply - streams-based objects that exist only because Node's http module predates any web-wide standard for representing an HTTP exchange in JavaScript.
Hono answers differently: a handler receives a standard Request object and returns a standard Response object, the exact same classes defined by the Fetch API and already implemented in every modern browser, in Deno, in Bun, and in edge runtimes like Cloudflare Workers.
Node itself has supported these global classes natively since version 18, so a Hono app running under @hono/node-server isn't faking a browser API - it's using the same one the runtime already provides.
A useful analogy: think of Request/Response as a shipping container standard.
Before standardized containers, every port needed its own specialized loading equipment for every kind of cargo; once everyone agreed on the container's shape, any crane at any port could move any cargo, because the equipment only needed to understand the container, not what was inside it.
Node's http.IncomingMessage is cargo shaped for one specific dock; the Fetch API's Request/Response is the shipping container - and a framework built around the container, not the dock, can move to any port that also speaks containers.
// Hono handler: a plain function from Request-ish context to Response
app.get("/users/:id", (c) => {
return c.json({ id: c.req.param("id") }); // c.json() returns a standard Response
});Koa sits in between: it still wraps Node's native http objects, but it replaced Express's callback-based middleware with async/await and a single ctx object early, which is why it's grouped with lightweight frameworks even though it isn't Web-Standards-based the way Hono is.
Polka goes the other direction entirely - it keeps Node's native objects and simply adds a fast, minimal router on top, trading portability for the smallest possible footprint on Node specifically.
The part of "lightweight" that actually changes how you write code is middleware composition, and it works the same way across Hono, Koa, and Express even though the underlying objects differ: middleware doesn't run in a flat, sequential list.
It nests, like layers of an onion, because each middleware function receives a next() callback and decides when - or whether - to call it.
request in
├─ logger middleware (work before next())
│ ├─ auth middleware (work before next())
│ │ ├─ route handler (innermost layer)
│ │ └─ auth: work after next() returns (e.g. response header)
│ └─ logger: work after next() returns (e.g. log duration)
└─ response out
Code registered before await next() runs on the way in, in registration order; code registered after await next() runs on the way back out, in reverse order - which is why a logging middleware that times a request has to wrap the call in next(), not just log once at the start.
This onion model is what makes middleware composable: an auth check can short-circuit by never calling next(), and a response-shaping middleware can inspect or rewrite what the handler produced before it reaches the client, because it's still "inside" the call when next() returns.
Under the hood, the Web-Standards choice also changes how a request reaches that middleware chain in the first place.
A Hono app's core has no idea it's running on Node at all - @hono/node-server is an adapter, a thin translation layer that listens on a real Node http.Server, converts each incoming IncomingMessage into a standard Request, hands it to the Hono app, and converts the Response that comes back into whatever Node's socket needs.
That adapter is the only Node-specific code in the whole stack; swap it for a Cloudflare Workers adapter (built into the platform, no translation needed) or a Bun adapter, and the exact same app object runs somewhere else, unmodified, because it never touched Node's objects to begin with.
"Lightweight" is really shorthand for two separate properties that don't always travel together: small footprint (fewer dependencies, smaller install size, less code to parse and JIT-compile at startup) and runtime portability (works outside Node without a rewrite).
Polka has the first property without the second - it's tiny, but it's Node-only by design.
Hono has both, because portability is what let its authors keep the core free of Node-specific code in the first place; a framework that reaches for Node's Buffer or process globals inside its core can't run unmodified on an edge runtime, so avoiding them is a constraint that happens to also shrink the dependency tree.
Footprint mainly earns its keep at cold start: on a serverless or edge platform, a new instance has to load and initialize the framework before it can handle its first request, and every megabyte of dependency code and every synchronous require() chain adds to that latency.
Once a Node process is warm and running steadily, though, the gap between Hono and Express narrows sharply - both are I/O-bound by the same event loop, and neither framework's own overhead is usually the bottleneck compared to database calls or serialization.
That's the honest trade-off: pick a lightweight framework for portability or cold-start-sensitive deployments, not on the assumption that it will make an already-warm Node service dramatically faster.
The ecosystem gap is the other real cost - Express has fifteen-plus years of middleware, Stack Overflow answers, and integration guides that a smaller framework's community hasn't accumulated yet, so teams sometimes end up writing small adapters or middleware themselves that would have been a one-line npm install in Express.
| Approach | Strength | Weakness | Best Fit |
|---|---|---|---|
| Hono (Web Standards core) | Runs unmodified on Node, Workers, Deno, Bun; tiny core | Smaller middleware ecosystem than Express | Multi-runtime deployments, edge/serverless APIs |
| Koa (async-first, Node-native) | Clean async/await middleware, minimal core, huge existing plugin catalog | Still tied to Node's http objects - no edge portability | Node-only services that want Express's ecosystem maturity with a cleaner core |
| Polka (Node-native, no abstraction) | Smallest possible overhead on Node; near-zero dependencies | Node-only, minimal built-in features (no built-in body parsing, etc.) | Latency-critical Node-only services with simple routing needs |
| Express (Node-native, batteries included) | Enormous ecosystem, most documented, safest default | Heaviest footprint of the four; not portable off Node | General-purpose Node APIs where ecosystem breadth outweighs footprint |
Framework Selection Checklist turns this comparison into a concrete decision process; Hono on Node vs Edge covers the specific runtime differences that matter once you've picked Hono.
Request/Response classes the browser defines, but it still runs server-side code with full Node API access through its adapter layer - it isn't sandboxed the way browser JavaScript is.http objects.next() returns, on the way back out, which is why ordering changes behavior in both directions.Its core avoids depending on Node-specific objects (like http.IncomingMessage) and Node-only globals, building instead on the standard Request/Response classes. That's what makes it both small and portable - the two usually travel together but aren't the same property.
An Express handler receives Node's native req/res objects and mutates res directly; a Hono handler receives a context wrapping a standard Request and returns a standard Response object, matching the same API a Fetch call or a Cloudflare Worker uses.
No - it means Hono's core reuses the same Request/Response classes a browser defines, so the shapes match, but the code still executes server-side with full runtime access through whichever adapter (Node, Workers, Bun) is running it.
Each middleware wraps everything registered after it, so code before await next() runs on the way in, in order, and code after next() runs on the way back out, in reverse order - moving a middleware earlier or later changes both when it sees the request and when it sees the response.
An adapter (@hono/node-server for Node) is the translation layer between a runtime's native objects and the framework's Web-Standard core - it converts an incoming IncomingMessage into a Request and converts the returned Response back into what Node's socket needs. It's the only Node-specific code in the stack.
Only on the footprint axis - Polka is Node-only and doesn't use the Web Standards Request/Response shape, so it's small but not portable to edge or non-Node runtimes the way Hono is.
Mainly at cold start, where less code to load and initialize matters most. Once a process is warm, framework overhead rarely dominates compared to database calls, serialization, and network I/O.
Because its core is unusually minimal for a Node-native framework - no built-in router or body parser, async/await-first middleware, and a small dependency footprint - even though it doesn't share Hono's edge portability.
Fewer pre-built, community-maintained middleware packages and fewer existing answers to common problems - teams sometimes write small integrations themselves that would already exist for Express.
Yes, on Node - the adapter gives handlers full Node runtime access. The constraint that keeps Hono portable is that its own core avoids depending on those globals, not that your application code can't use them when running on Node specifically.
No - it's common to use Express or Fastify for a Node-only monolith and Hono specifically for services that need to run on an edge platform or be portable, choosing per-service based on where that service actually deploys.
No - the standard Response constructor accepts a ReadableStream body, so streaming works the same conceptual way it does with Node streams, just expressed through the Web Streams API instead of Node's stream classes.
Stack versions: This page was written for Node.js 24 LTS, npm 10+, and TypeScript 5.6+.
Reviewed by Chris St. John·Last updated Jul 15, 2026