Hono vs Express in 2026: Edge-Ready vs Battle-Tested

Why This Comparison Matters in 2026

Express has been the default answer to "how do I build a Node.js API" since 2011. It's stable, predictable, and carries an ecosystem so large it's almost embarrassing. Then Hono showed up — written by Yusuke Kawasaki, first released in 2022 — and started winning benchmarks by uncomfortable margins while also running natively on Cloudflare Workers, Deno Deploy, and Bun. That changes the conversation in ways that weren't true even two years ago.

In practice, the choice between them isn't purely a speed contest. You're picking a runtime target, a middleware philosophy, and an ecosystem bet all at once. Most teams haven't thought that hard about it — they just reach for Express out of muscle memory, or they see a Hono tweet go viral and assume they should migrate everything. Neither reflex is right.

This article gives you the actual technical differences, with code you can run today, so you can make a decision that fits your use case rather than the benchmark leaderboard.

What Hono Actually Is (and Isn't)

Hono isn't just "fast Express." It's a framework built on the Web Standard APIs — Request, Response, URL, Headers — which means the same code runs on Node.js 18+, Cloudflare Workers, Bun, Deno, and AWS Lambda@Edge without runtime-specific shims. That's the real pitch, not the microsecond latency numbers.

The routing API is deliberately Express-like so the learning curve is shallow. app.get(), app.post(), middleware via app.use() — it'll feel familiar in about 10 minutes. Where it diverges is in the middleware model: Hono middlewares return a Response and chain with await next(), which is closer to Koa than classic Express and avoids the callback-era (req, res, next) footgun where forgetting next() silently swallows requests.

// Hono — basic route + middleware
import { Hono } from 'hono';
import { logger } from 'hono/logger';
import { cors } from 'hono/cors';

const app = new Hono();

app.use('*', logger());
app.use('/api/*', cors());

app.get('/api/hello', (c) => {
  return c.json({ message: 'Hello from Hono', runtime: c.runtime });
});

export default app; // works on CF Workers, Bun, Node adapter

Worth noting: Hono ships a Node.js adapter (@hono/node-server) that wraps Node's http module so you're not locked out of traditional VPS deploys. It's a thin shim — about 200 lines — but it exists and it works. You don't have to go all-in on edge to benefit from Hono's model.

Express in 2026: Still Relevant, But Showing Its Age

Express 5.0 finally shipped a stable release in 2024 after years of release candidates. It adds async error handling (no more wrapping every async handler in a try/catch or an express-async-errors shim), drops some deprecated APIs, and updates Node.js compatibility. It's a meaningful improvement. That said, Express 5 didn't touch the fundamental architecture — it's still built on Node's IncomingMessage/ServerResponse types, which predate the Fetch API by a decade.

That legacy isn't a flaw, exactly. It means Express talks directly to Node's HTTP layer with almost zero abstraction overhead. For a monolith deployed on a single EC2 instance, that's fine. The problem surfaces when you want to share route handlers between a serverless function and a Cloudflare Worker, or when you want to run the same middleware on the edge before a request even hits your origin. Express simply wasn't designed for that world.

// Express 5 — same hello world
import express from 'express';

const app = express();

// Express 5: async errors propagate automatically
app.get('/api/hello', async (req, res) => {
  const data = await fetchSomeData(); // throws? Express 5 catches it
  res.json({ message: 'Hello from Express', data });
});

app.listen(3000);

The ecosystem argument for Express is real and shouldn't be dismissed with a wave of the hand. Passport.js, Multer, Morgan, Helmet, Rate-limiter-flexible — these are mature, widely audited libraries that integrate directly with Express's req/res API. Hono has equivalents for most of them, but they're younger and occasionally less battle-hardened. If you're building auth flows or file upload pipelines and you want 10 Stack Overflow answers for every edge case, Express still wins that fight in 2026.

Honestly, Express is the TypeScript any of frameworks. It just works, it gets out of your way, and you can feel slightly embarrassed using it in polite company. Doesn't mean it's wrong.

Performance: The Real Numbers

Benchmarks are easy to game and easy to misread. Let's be specific. On a Cloudflare Worker serving a JSON response under TechEmpower-style load (plaintext + JSON tests, June 2026 numbers), Hono consistently hits around 300k–400k req/s on their infrastructure. Express running on a Node.js 22 process behind the same edge network tops out around 80k–120k req/s for equivalent work. That's a 3–4x gap. Significant, but also: are you hitting those numbers?

On a $20/month VPS doing a typical SaaS workload — auth checks, a database query or two, JSON serialisation — the bottleneck is almost always I/O, not framework overhead. Express at 100k req/s is more than enough for an API serving 50k daily active users. The performance argument for Hono becomes genuinely decisive only when you're paying per CPU-millisecond on edge compute or when you're building something latency-sensitive like a real-time pricing feed.

# Quick local benchmark with autocannon
npx autocannon -c 100 -d 10 http://localhost:3000/api/hello

# Hono (Bun runtime)      ~95,000 req/s
# Hono (Node adapter)     ~48,000 req/s
# Express 5 (Node)        ~32,000 req/s

Quick aside: these numbers are on M3 Pro hardware running locally. Your production numbers will differ based on network, instance type, and what the handler actually does. Treat them as relative ratios, not absolutes. The Hono-on-Bun number is especially misleading in isolation — a lot of that speedup is Bun's runtime, not Hono itself.

TypeScript DX: Where Hono Genuinely Pulls Ahead

This is the comparison that actually changes minds on teams I've talked to. Hono ships a typed RPC client called hono/client that lets you share your route types between server and frontend with zero code generation. You define routes on the server, export the app type, import it in your React or Next.js client, and get fully typed fetch calls — parameters, query strings, response bodies, all of it. In 2026, with tRPC and React Query raising developer expectations for type safety, this matters a lot.

// server.ts
import { Hono } from 'hono';

const app = new Hono().get(
  '/api/user/:id',
  async (c) => {
    const id = c.req.param('id');
    const user = await db.user.findUnique({ where: { id } });
    return c.json(user);
  }
);

export type AppType = typeof app;

// client.ts (React, Next.js, anywhere)
import { hc } from 'hono/client';
import type { AppType } from '../server';

const client = hc<AppType>('http://localhost:3000');

// fully typed — id is string, response is your User type
const res = await client.api.user[':id'].$get({ param: { id: '42' } });
const user = await res.json();

Express has no equivalent. You get req.params typed as Record<string, string> and res.json() typed as void. Teams working around this usually reach for OpenAPI code generation (openapi-typescript), which works but adds a build step and a schema maintenance burden. Hono's approach is lighter and more integrated.

One more thing — Hono's c.var pattern for passing typed context between middlewares is clever. You declare what a middleware injects (Variables interface), and every subsequent handler in the chain gets autocomplete for those values. Express's req.user pattern involves module augmentation declarations scattered across your project and is a TypeScript papercut you stop noticing only because you've had it for years.

When to Pick Which

Pick Hono when: you're targeting Cloudflare Workers or any edge runtime; you want that typed RPC client without tRPC; your team is greenfield and has no existing Express dependencies; or you're building on Bun and want to squeeze every millisecond. The migration cost from zero is low — the API surface is small and the docs are genuinely good.

Pick Express when: you're maintaining an existing codebase that already has 47 Express middlewares wired together; you need Passport.js and don't want to port your auth strategy; you're deploying to a traditional Node.js host and have zero interest in edge compute; or your team is less experienced and you want answers to every conceivable problem to exist on the first Google results page. That's not settling — that's engineering pragmatism.

Look, there's also a third option most articles don't mention: Fastify. If you want to stay in the Node.js ecosystem but want better TypeScript support than Express and faster JSON serialisation (it uses a JSON schema-to-serializer compiler that's measurably faster than JSON.stringify for shaped data), Fastify hits a middle ground that neither Express nor Hono occupies. Not the point of this article, but worth keeping in it your head.

The mistake to avoid is treating this as an identity choice. Hono on the edge, Express in a Lambda, Fastify for the core API — nothing stops you from having all three coexist in a monorepo. The Web Standard API compatibility actually helps here: middleware you write for Hono can often be ported to Express in 20 minutes because the underlying HTTP concepts are identical.

If you're building the frontend alongside your API, Empire UI's templates cover several API-connected patterns — authentication dashboards, SaaS pricing pages, admin panels — that you can pair with either framework. The components don't care what's behind the API. Browse the full component library for what you can ship on the UI side while you're sorting out the backend choice.

Migrating from Express to Hono (or the Other Way)

Going Express → Hono is usually straightforward for simple CRUD APIs. The main friction points are: (1) middleware signature change — (req, res, next) becomes async (c, next) => {}, (2) response methods — res.json() becomes c.json(), res.status(404).json() becomes c.json({}, 404), and (3) accessing the body — req.body (Express with express.json()) becomes await c.req.json().

// Express handler
app.post('/api/items', async (req, res) => {
  const body = req.body; // via express.json() middleware
  const item = await db.create(body);
  res.status(201).json(item);
});

// Same handler in Hono
app.post('/api/items', async (c) => {
  const body = await c.req.json();
  const item = await db.create(body);
  return c.json(item, 201);
});

Going Hono → Express is rarer but happens when a team adopts Hono early and then discovers a critical Express-specific library they can't replace. The migration is equally mechanical in the other direction — just reverse the patterns above. You'll lose the typed RPC client, which stings, but you probably knew that going in.

Worth noting: Hono has an Express compatibility layer (@hono/connect-middleware) that lets you drop existing Express/Connect middlewares into a Hono app without rewriting them. It's not magic — some middlewares that mangle res directly won't work — but for common middleware like rate limiters and CORS handlers that use next() idiomatically, it covers you during a gradual migration.

FAQ

Read next