Express shaped the Node.js API ecosystem. Koa refined its middleware model, while Hono brought a compact, standards-oriented approach to edge and multi-runtime applications. All three can serve a TypeScript API, but their strengths appear under different constraints.

Express: optimise for familiarity#

Express remains the lowest-risk choice when hiring reach, middleware availability, and compatibility dominate the decision. Its programming model is widely understood, integrations are plentiful, and almost every hosting platform can run it without explanation.

Maturity does not automatically create structure. A growing Express application needs clear conventions for route composition, validation, error handling, authentication, and async behaviour. Avoid passing loosely typed request objects deep into the system. Validate at the boundary, map input to application commands, and keep domain logic independent of Express.

The ecosystem’s size also deserves caution. Prefer actively maintained dependencies with narrow purposes. Many historical tutorials recommend packages or patterns that are no longer necessary in current Node releases.

Choose Express for established Node environments, broad integrations, conservative migration paths, and teams that value familiarity.

Koa: middleware as composition#

Koa was created by members of the original Express team with a smaller core and an elegant async middleware model. Its cascading flow lets middleware perform work before and after downstream handlers, which suits tracing, timing, transactions, and consistent response transformation.

Koa provides fewer built-in decisions. Routing, validation, security headers, and other common needs generally come from separate packages. This is useful for teams that want precise composition, but it increases the importance of maintaining an approved platform layer. Without one, different services can assemble incompatible conventions.

Choose Koa when middleware composition is central, the team is comfortable curating dependencies, and Node is the expected runtime.

Hono: web standards across runtimes#

Hono is designed around web-standard primitives such as Request and Response. It can target traditional Node deployments as well as edge and serverless runtimes. Its compact API, typed routing options, and fast startup characteristics make it appealing for new services that need portability or low-latency execution close to users.

Edge deployment changes more than the framework. Runtime APIs, connection behaviour, filesystem access, execution limits, and database location all matter. An endpoint running near the user still feels slow when every request crosses a continent to reach its database. Confirm that required libraries support the selected runtime and design data access alongside compute placement.

Choose Hono for greenfield TypeScript APIs, edge functions, multi-runtime portability, and teams comfortable with a newer ecosystem.

Compare a vertical slice#

Implement one complete operation in each serious candidate: authentication, schema validation, a database call, a structured error, logging, and a test. Compare the resulting code and deployment artifact, not synthetic routing benchmarks.

Also consider exit cost. Applications with domain logic separated from HTTP adapters can move between these frameworks without a rewrite. When framework objects leak through every layer, even a small service becomes locked in.

Express is the mature default, Koa is the compositional toolkit, and Hono is the portable modern option. The right selection follows the runtime, team, and operational model—not the popularity of a benchmark screenshot.