What actually changes in your day when you pick Hono, Express, or Fastify for a new backend? Not the benchmark charts. The real answer lives in the small habits each framework forces on you: how you register a route, how you catch an error, how you test a handler, and how much structure you have to invent before the first feature ships. Those habits compound. A framework that saves ten minutes on setup but costs an hour a week in friction is a bad trade, and the reverse is true too.
This comparison focuses on workflow, not raw speed. All three frameworks can serve a production API. The difference is what your team does every day to keep it running.
The mental model each framework asks you to adopt
Express is the oldest of the three and still the reference point most developers learn first. Its model is a flat chain of middleware functions with the signature `(req, res, next)`. Every request walks through the chain in order. Each function either responds or calls `next()` to hand off to the following handler. That simplicity is why Express has stayed popular for over a decade, and it is also why large Express codebases tend to drift into a tangle of middleware whose execution order nobody can reconstruct from memory.
Fastify keeps the idea of middleware but formalizes it. Its central unit is the plugin, registered with `fastify.register()`, and each plugin gets its own encapsulated scope. A plugin that adds a decorator or a hook does not leak it to sibling plugins unless you deliberately break encapsulation. That single rule changes how you organize a project: features become plugins, and the boundaries are enforced by the framework rather than by convention.
Hono takes a third path. It is built on the Fetch API’s `Request` and `Response` objects, and its entry point is `app.fetch(request)` rather than a Node-style `listen()` call. Middleware uses a `(c, next)` signature with a context object, closer in spirit to Koa than to Express, and handlers compose with `await next()`. The payoff is portability: the same app runs on Node.js, Deno, Bun, Cloudflare Workers, and other runtimes without a rewrite.
| Aspect | Express | Fastify | Hono |
|---|---|---|---|
| Handler signature | `(req, res, next)` | `(request, reply)` | `(c, next)` |
| Core unit | Middleware chain | Encapsulated plugin | Route + context |
| Entry point | `app.listen()` | `fastify.listen()` | `app.fetch(request)` |
| Validation | Bring your own | Built-in JSON Schema | Bring your own or use validators |
| Runtime target | Node-centric | Node-centric | Multi-runtime, edge-first |
Routing and request handling in daily use
Express routing is readable and forgiving. `app.get(‘/users/:id’, handler)` does what it looks like. The catch is version drift. Express 5.0.0 landed on 31 October 2024 after a long beta, and it changed path matching syntax inherited from path-to-regexp, along with several legacy behaviors. Teams migrating from Express 4 should read the official Express 5 migration guide before upgrading, because the changes touch routing patterns and error handling rather than just internals. A route that worked in 4.x can behave differently in 5.x, and the surprise usually shows up in staging rather than in the changelog.
Fastify’s routing looks similar on the surface but rewards a different habit: declaring schemas alongside the route. You describe the body, params, query, and response with JSON Schema, and Fastify uses those definitions for both validation and serialization. The serialization step is not cosmetic. Fastify compiles response schemas into fast-json-stringify functions, which is a meaningful part of why it performs well. The workflow consequence is that schemas arrive first, not as an afterthought. If your team tends to bolt validation on at the end, Fastify will feel like it is arguing with you. If your team already writes schemas, it feels like the framework finally agrees with you.
Hono’s routing is concise, and the context object `c` carries request data, response helpers, and variables you set along the way. Because the app is a function from `Request` to `Response`, you can test it without a network socket and deploy it to an edge runtime without changing the handler code. That portability is the whole pitch, and it holds up in practice. What it does not do is give you Fastify’s schema-first discipline or Express’s enormous body of tutorials and Stack Overflow answers.
Error handling is where workflows quietly break
Ask any team that has migrated between these frameworks what hurt most, and error handling usually tops the list.
In Express 4, an async handler that throws does not automatically reach your error middleware. The rejected promise floats away, the request hangs, and you find out from a timeout. Express 5 fixed this by forwarding rejected promises to error middleware, which is genuinely better, but it means the same code behaves differently across major versions. A codebase that mixes both without a clear policy is a codebase with intermittent hangs.
Fastify handles errors through `setErrorHandler` and its lifecycle hooks. Because hooks run at defined stages (`onRequest`, `preHandler`, `preSerialization`, `onSend`), you know exactly where a failure can be caught and what has already happened to the request. That predictability is worth a lot on a team of more than two people. The trade-off is that you must learn the hook order. Guessing at it produces bugs that look like framework bugs but are actually sequencing mistakes.
Hono’s `await next()` composition makes error flow explicit in the code you read. A middleware wraps downstream handlers, and a `try`/`catch` around `await next()` catches what happens below it. That is easier to reason about than a flat chain, though it does require developers to think in terms of nesting rather than linear order.
Project structure and how much you have to invent
Express gives you nothing beyond the router. Folder structure, validation, logging, configuration, and testing conventions are all decisions your team makes. That freedom is real, and so is the cost: every new Express project reinvents the same five decisions, usually slightly differently.
Fastify nudges you toward a structure. Feature folders become plugins, shared utilities become decorators, and cross-cutting concerns become hooks. The encapsulation model means a plugin’s additions stay local unless you opt out with `fastify-plugin`. Teams that adopt this pattern early report that onboarding gets easier, because a new developer can read one plugin folder and understand one feature without tracing the whole app.
Hono sits somewhere in between. Its API is small and composable, and the runtime target shapes the structure. An app destined for Cloudflare Workers will organize around bindings and environment variables differently than one running on a long-lived Node process. If your team is weighing deployment targets, it is worth reading a practical breakdown of Dropbox alternatives by use case or Google Drive alternatives by use case only insofar as it illustrates a broader point: tool choice should follow the workflow, not the other way around. The same logic applies to frameworks.
Testing workflows compared
This is the most underrated difference between the three.
| Testing approach | Express | Fastify | Hono |
|---|---|---|---|
| In-process request | Needs supertest or a live server | `fastify.inject()` | `app.request()` |
| Port binding required | Usually yes | No | No |
| Typical speed | Slower | Fast | Fast |
| Edge runtime tests | Not applicable | Not applicable | Native |
Fastify’s `fastify.inject()` sends a request through the full lifecycle without opening a socket. Hono’s `app.request()` does the same in Fetch style. Express traditionally requires supertest or a running server, which is fine but adds a layer. Over a year of test runs, the difference between “fast” and “fine” adds up to real developer patience.
TypeScript ergonomics
Hono is written in TypeScript and infers route parameters and context types from your route definitions, so handlers usually know their own types without annotation. Fastify ships TypeScript types and pairs them with schemas, which gives you runtime and compile-time safety from one source. Express historically relied on `@types/express` with weaker inference, and the state of Express 5 typings is worth checking directly rather than assuming.
If your team writes a lot of TypeScript, this difference shows up in editor feedback more than in documentation. Autocomplete quality is a workflow feature.
Practical tips that save real time
- Pick one error-handling pattern and write it down. Every framework supports several; mixing them is what causes mystery bugs.
- In Fastify, learn the hook order before you write your first plugin. Draw it once and keep it nearby.
- In Express, decide on async error handling explicitly, especially if any part of the codebase is still on 4.x.
- In Hono, test with `app.request()` from day one. It keeps tests fast and portable.
- Write schemas or validators before handlers, whichever framework you choose. Retrofitting validation is always more expensive.
A common mistake is choosing a framework by benchmark and then discovering the team’s actual bottleneck was schema discipline or test speed. Another is assuming a framework’s structure will organize the project for you. Only Fastify really tries, and even it needs a team that follows the pattern. (An overview of HTTP)
Common mistakes and what actually works
The most frequent error is treating Express 5 as a drop-in replacement for Express 4. It is close, but the routing and async changes are real, and a staged migration with tests at each step beats a single big-bang upgrade.
The second is adopting Fastify’s plugins without understanding encapsulation, then wondering why a decorator is missing in one route and present in another. Reading the plugin documentation once, carefully, prevents weeks of confusion.
The third is choosing Hono for a Node-only monolith where edge portability adds no value. Hono is excellent, but its biggest advantage is irrelevant if you never leave one runtime. If your workflow is already settled and you are comparing tooling more broadly, pieces like a practical Claude writing workflow or a comparison of Claude alternatives by workflow and price show the same principle at work: fit beats features.
Conclusion
The honest summary is that all three frameworks are good, and the choice comes down to which daily habits you want enforced. Express offers maximum familiarity and minimum opinion, at the cost of inventing your own structure and being careful about async errors. Fastify trades a learning curve for encapsulation, schema-first validation, and fast in-process testing. Hono trades Node-centric familiarity for portability across runtimes and a clean context-based middleware model.
Pick based on where your team spends its hours, not on a benchmark chart. Then commit to the conventions the framework rewards, and the workflow differences stop being trivia and start being the reason your project ships on time.
FAQ
Is Express 5 a drop-in replacement for Express 4?
No. Express 5.0.0 shipped on 31 October 2024 with changes to routing syntax and promise rejection handling, among other adjustments. Most code migrates cleanly, but routes with unusual path patterns and async handlers that relied on manual error forwarding need review. Test thoroughly before switching a production app.
Which framework is fastest, Hono, Express, or Fastify?
Benchmark results depend heavily on the workload, the runtime, and the benchmark’s methodology, so no single answer holds. Fastify’s schema-based serialization gives it an edge on JSON-heavy APIs, while Hono performs well in edge environments. Treat published numbers as a starting point and measure your own endpoints.
Do I need TypeScript to use Hono?
No. Hono works with plain JavaScript, but it is written in TypeScript and its type inference is one of its strengths. Teams using TypeScript get better editor feedback on route parameters and context objects. JavaScript users lose that convenience but nothing functional.
Can I run Express or Fastify on edge runtimes?
Both are primarily designed around Node.js and a long-lived server process. Hono is built on the Fetch API specifically to run across Node.js, Deno, Bun, Cloudflare Workers, and similar environments. If edge deployment is a hard requirement, that difference usually decides the choice. (Node.js)
How does Fastify’s plugin encapsulation affect project structure?
Each plugin registered with `fastify.register()` gets its own scope, so decorators and hooks added inside it do not affect sibling plugins unless you use `fastify-plugin` to opt out. In practice this encourages organizing code by feature, with each feature folder self-contained and its boundaries enforced by the framework.
What is the biggest workflow difference between the three?
Error handling and testing. Express requires deliberate decisions about async errors and usually needs a live server or supertest for tests. Fastify defines error handling through hooks and offers in-process injection. Hono composes errors through `await next()` and tests through `app.request()`. Those habits shape daily work more than routing syntax does.
