We earn commissions when you shop through the links below.
The debate around Hono vs Express for edge applications has become one of the most practical conversations in backend development right now. Express has been the default Node.js framework for over a decade. Hono is the new kid that actually runs on Cloudflare Workers, Deno Deploy, Bun, and Fastly — environments where Express simply can’t go. If you’re building anything that needs to run at the edge, this comparison matters a lot.
The Core Problem with Express at the Edge
Express was built in the Node.js era, which means it relies on Node.js APIs: http, Buffer, process, and the familiar Node.js request/response objects. Edge runtimes don’t run Node.js. They run a stripped-down, WinterCG-compatible JavaScript runtime built around the Web Fetch API — Request, Response, Headers, URL.
This isn’t a minor detail. Express middleware, body parsing, cookie handling — all of it is built on top of Node.js primitives that simply don’t exist in a Cloudflare Worker or a Deno Deploy function. You can run Express on a traditional VPS (something like Railway handles this well), but if you want to deploy to the edge, you need a framework designed for it.
What Is Hono?
Hono is a small, fast, Web Standards-based web framework. Its entire API is built around the Fetch API spec, which means the same code runs on Cloudflare Workers, Deno, Bun, AWS Lambda, Node.js (via an adapter), and Fastly Compute. The name means “flame” in Japanese, and the performance numbers back it up.
A basic Hono app looks like this:
import { Hono } from 'hono'
const app = new Hono()
app.get('/', (c) => {
return c.text('Hello from the edge!')
})
app.get('/user/:id', async (c) => {
const id = c.req.param('id')
return c.json({ userId: id, timestamp: Date.now() })
})
app.post('/data', async (c) => {
const body = await c.req.json()
return c.json({ received: body }, 201)
})
export default app
If you’ve written Express before, this feels immediately familiar. The routing API is almost identical. But under the hood, c.req is a wrapper around the native Request object, and c.json() returns a native Response. No Node.js in sight.
A Comparable Express App
Here’s the same thing in Express, for comparison:
import express from 'express'
const app = express()
app.use(express.json())
app.get('/', (req, res) => {
res.send('Hello from the server!')
})
app.get('/user/:id', (req, res) => {
const { id } = req.params
res.json({ userId: id, timestamp: Date.now() })
})
app.post('/data', (req, res) => {
res.status(201).json({ received: req.body })
})
app.listen(3000)
The DX is nearly the same. But this code only runs on Node.js. Deploy it to Cloudflare Workers and it breaks immediately.
Performance: The Numbers
Benchmarks consistently show Hono outperforming Express on raw throughput and latency when running in Node.js mode — and it’s not even close on edge runtimes because Express can’t run there at all.
On Bun, Hono regularly hits 100k+ requests per second on simple routes. Express on Node.js typically tops out around 15-25k req/s on similar hardware. Part of this is the runtime difference (Bun vs Node.js), but part of it is also that Hono’s router (called RegExpRouter) is genuinely fast — it pre-compiles route patterns rather than iterating through them on every request.
For API-heavy applications where latency matters, this difference is real. For a low-traffic internal tool, it won’t matter at all.
Middleware Ecosystem
Express wins here, and it’s not close. The npm ecosystem has 15+ years of Express middleware. Authentication, rate limiting, multipart uploads, session management — there are battle-tested packages for all of it.
Hono ships with a solid set of built-in middleware: JWT auth, CORS, compression, bearer auth, basic auth, request timing, and more. For most use cases this is enough. But if you need something niche, you might find yourself writing it from scratch or wrapping an existing library carefully to work with Web API types.
The Hono team is also actively building an ecosystem of third-party middleware, and the community is growing fast. But if you’re building something complex today and you need a rich middleware ecosystem, Express (or Fastify) still has the advantage.
TypeScript Support
Hono has first-class TypeScript support baked in from day one. Route parameters, query strings, JSON bodies — you can type all of it with Hono’s validator middleware and get end-to-end type safety. Hono’s RPC mode even lets you share types between your server and a TypeScript client automatically.
import { Hono } from 'hono'
import { zValidator } from '@hono/zod-validator'
import { z } from 'zod'
const app = new Hono()
const schema = z.object({
name: z.string(),
age: z.number().int().positive(),
})
app.post('/register', zValidator('json', schema), (c) => {
const { name, age } = c.req.valid('json')
// name and age are fully typed here
return c.json({ message: `Registered ${name}, age ${age}` })
})
export default app
Express has @types/express, which is fine, but adding runtime validation and connecting it to TypeScript types requires more manual wiring. Hono makes this ergonomic out of the box.
When to Choose Hono
- You’re deploying to Cloudflare Workers, Deno Deploy, or Fastly Compute. Hono is the obvious choice — Express literally doesn’t work here.
- You’re using Bun as your runtime. Hono + Bun is an extremely fast combination.
- You want strong TypeScript ergonomics from the start. Hono’s type system is excellent.
- You’re building a new project and want to avoid Node.js lock-in. Hono’s Web Standards foundation means you can move between runtimes more easily.
- You care about bundle size. Hono is tiny — the core is around 14kb, making it suitable for environments with bundle size limits.
When to Choose Express
- You’re maintaining an existing codebase. Migrating a large Express app to Hono has a cost that may not be worth it.
- You rely heavily on npm middleware that assumes Node.js APIs. Passport.js, Multer, and similar packages won’t work in Hono without adaptation.
- Your team knows Express deeply and you’re not hitting performance ceilings. Don’t switch for the sake of switching.
- You need a traditional server deployment on a VPS or container. Express on a Node.js server behind a load balancer is a completely valid architecture.
Deployment Considerations
Where you host matters as much as which framework you pick. If you’re running a traditional Express API on a container or VM, a straightforward platform like Railway removes most of the DevOps overhead — you push code, it builds and deploys, you’re done. Railway also handles Hono apps running on Node.js or Bun with no additional configuration.
If you want to go full edge with Hono, Cloudflare Workers’ free tier is generous and their tooling (wrangler) makes local development smooth. You get global distribution with sub-10ms cold starts essentially for free at modest traffic levels.
The Verdict
When you’re evaluating Hono vs Express for edge applications, the answer is almost always Hono — because Express isn’t a real option in most edge environments. The better question is whether you’re actually building for the edge or whether you’re building a traditional server-side application.
If the answer is edge, Hono. If the answer is a traditional Node.js server where you already have a lot invested in Express middleware, stick with Express or consider Fastify as a modern alternative that also stays in the Node.js world.
The good news is that if you know one, learning the other takes about a day. The routing APIs are similar enough that the knowledge transfers. The difference is what’s underneath — and for Hono vs Express for edge applications, that difference is everything.
If you want to go deeper on modern JavaScript backend patterns, Udemy has solid courses on Cloudflare Workers and edge deployment that pair well with getting started with Hono.