The Hono Framework: A Hands-On Web-Standards Take

#Redefining it: what is Hono from a systems-architecture view?

Most intros call Hono "a faster Express for the edge." That is easy to grasp but it ruins the real story.

The core difference is not speed — it is the compatibility layer. Express is written on Node's own req/res, an API more than a decade old that only exists inside Node. Hono is written on the Web Standards (WinterCG) Request/Response — the very objects you already use when you call fetch() in a browser.

The architectural consequence is large: because Hono only speaks the runtime's "common tongue," the same handler runs on Cloudflare Workers, Bun, Deno, Node, Vercel Edge, Fastly, and Lambda with almost no changes. You do not lock your architecture into one vendor. For someone who has to think about a system's 3-5 year lifespan, "not locked into a runtime" is an asset, not a nice-to-have.

#Why I tried Hono (the real context)

This site deploys on Cloudflare Pages and has a few serverless functions (for example, a proxy endpoint that calls PageSpeed Insights so the API key never reaches the client). As the number of functions grew, two very real problems showed up:

1. Cold start and CPU budget. Workers bill by CPU time and have hard limits. Drop a heavy Node framework in here and it either won't run or eats an uncomfortable cold start. I needed something that starts almost instantly.
2. Types break at the network boundary. The frontend calls a function, but the request/response shapes have to be synced by hand. Change one endpoint's shape and you go fix the call sites manually — and TypeScript won't catch it for you.

Hono solves both at once, so I moved the API layer onto it.

#Real code: routing and middleware

This is the part that felt "lighter" immediately. Middleware isn't a pile of separate installs — it lives in the core:

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/health', (c) => c.json({ ok: true }))

app.get('/api/posts/:id', (c) => {
  const id = c.req.param('id')      // inferred as string
  return c.json({ id })
})

export default app                  // on Workers, export default is all you need

No app.listen(), no server.js. On Cloudflare Workers, export default app is enough — because Hono speaks exactly the fetch-handler contract the runtime expects. Middleware runs in registration order: the "before next()" part of the first-registered middleware runs first, and its "after next()" part runs last. Understanding this matters when you stack auth, cache, and error handlers.

#The best part: codegen-free type-safe RPC

This is the feature that kept me. You define a route with a validator, then export type that route:

import { Hono } from 'hono'
import { zValidator } from '@hono/zod-validator'
import { z } from 'zod'

const app = new Hono()

const route = app.post(
  '/posts',
  zValidator('json', z.object({ title: z.string(), body: z.string() })),
  (c) => {
    const data = c.req.valid('json')   // already Zod-validated and typed
    return c.json({ ok: true, id: 1 }, 201)
  }
)

export type AppType = typeof route

On the client you create an hc (Hono Client) and pass it AppType:

import { hc } from 'hono/client'
import type { AppType } from './server'

const client = hc<AppType>('https://api.example.com/')

const res = await client.posts.$post({
  json: { title: 'Hono', body: 'tried it on Workers' },
})

if (res.ok) {
  const data = await res.json()   // data.id is inferred, no manual casting
}

No codegen step, no generated OpenAPI file to rebuild, no extra server. Types travel straight from the route definition to the call site through an ordinary import. Change the schema on the server and TypeScript goes red on the client immediately. This is what tRPC does, but Hono does it on plain HTTP/fetch instead of a bespoke protocol.

#A practical comparison: Hono vs Express vs Elysia

The figures below come from public benchmarks and direct experience — absolute numbers depend on the environment, but the relative ranking is stable.

Read the table like an architect: Elysia wins on raw throughput and the smoothness of its types, but it is tied tightly to Bun. Hono sits at the most balanced point — fast, small, good types, and it runs everywhere. Express is still fine for a traditional Node monolith, but at the edge it's the wrong tool.

#Real-world gotchas: things few people warn you about

No framework is free. Here are three that cost me time:

1. Hono's types are "optimistic." Variables set via c.set() are typed at the app's global scope, so TypeScript lets you read c.var.db even on a route where the middleware that sets it never ran. It's green in the IDE but undefined at runtime.

app.use('/admin/*', async (c, next) => {
  c.set('db', createDb(c.env))
  await next()
})

app.get('/public', (c) => {
  const db = c.var.db   // no TS error, but this route skips the middleware -> undefined
})

This is a deliberate trade-off for a clean DX, but it demands discipline: which middleware sets which variable, and which route passes through it, is something you keep straight in your head or your folder structure.

2. ESM-only. Hono and @hono/node-server are ESM-only. If your project still has CommonJS, you'll hit module-resolution errors at runtime. Worth knowing before you drop it into an old codebase.

3. HonoX (the meta-framework) is still alpha. If you dream of a Next-style full-stack framework on Hono, HonoX is that direction — but minor versions can still break. For production today, the safe recipe is Hono for the API + a separate frontend, then track HonoX until it stabilizes.

One small tip from the docs that I confirmed: with many routes, compile first before opening the IDE, otherwise TypeScript's RPC inference can make the editor sluggish. And avoid c.notFound() with RPC — use c.json({...}, 404) so the status code makes it into the type.

#When should you use Hono, and when not?

The short version: Hono is worth it for an edge API layer or microservice, and when you want end-to-end type safety without taking on tRPC/OpenAPI. Conversely, a stable Express monolith that just works shouldn't be migrated to chase a trend — that's negative value.

But this is a decision about cost and risk more than about technology — especially because you can't migrate from Express to Hono incrementally.

#Reframing it: adopting a framework is a Delivery decision, not a technical one

A pretty benchmark convinces an engineer in five minutes. But what actually decides whether an adoption succeeds or fails in practice is: the cost of the rewrite, the time the team needs to get fluent, how available libraries are when you hit an edge case, and whether you can hire someone to maintain it in two years. Those are all Delivery variables, not variables in a speed test.

Put differently: "Hono is faster than Express" is almost irrelevant to whether you should put it into a system that's already running. Here's the framework I use.

#Why migration cost is the biggest variable

This is the part many people skip: you can't move routes one at a time from Express to Hono inside the same app. Express is tied to Node's req/res; Hono is tied to Web Standards Request/Response. The two request/response models are fundamentally different, so there's no clean "wrap it and run side by side" path within one codebase.

The practical consequences:

• Every route handler must be rewritten, not patched.
• Express-specific middleware (passport, multer, express-session...) must be replaced with Web-Standards-compatible versions — most have equivalents in the @hono/* ecosystem, but not 1-to-1 for every case.
• So the safe strategy is a service-level strangler pattern: build the new service/microservice in Hono, let the old one keep running, and don't mix two frameworks in one app.

That means migration cost is not linear in "number of routes" — it's a rewrite-by-chunk decision. For a large, stable Express codebase, this number usually exceeds the benefit, and the answer is no.

#The 5-axis decision matrix

I score Hono on five axes. If most lean to the right column, adopt; if they lean left, don't.

How to read it: Current state and Target runtime carry the most weight, because they decide the migration cost. Those two alone are enough to rule in or out in most cases.

#Hidden costs few people budget for

Beyond migration, there are costs that don't show up on a benchmark:

• A ~4-year-old ecosystem. The Hono core is production-ready and downloads have grown sharply (into the tens of millions per week by 2026), but it's still a decade younger than Express. Occasionally you'll write a middleware that on Express is a one-line npm install. Budget engineer-hours for that.
• Hiring and bus factor. Express has a deep candidate pool and a decade of docs. Hono is capturing most new Node backend apps, but the pool of people who've run it in production is still smaller. Ask: who maintains this in two years?
• Observability at the edge. Running on Workers means entering the edge observability model: logs/metrics go through the platform's tooling, distributed rate limiting often needs Durable Objects, caching uses the Cache API. Not hard, but a different operational model — with a learning cost.
• ESM-only. If your legacy infra still has CommonJS, that's a cleanup cost to count.

#Three go/no-go scenarios

Scenario A — Greenfield edge API → YES. You're building a new API/gateway layer or microservice on Cloudflare Workers/Deno, needing millisecond cold starts and end-to-end type safety. This is Hono's home turf. No migration cost, only upside. Adopt.

Scenario B — Stable Express monolith → NO. You have a large Express app, lots of middleware, serving well. Migrating means rewriting all handlers and replacing middleware — high cost, high risk, low marginal benefit. If you genuinely need edge, split out a new service in Hono via the strangler pattern; don't touch the monolith.

Scenario C — Need a full-stack framework in production now → WAIT. You want something Next-like but on Hono (HonoX). Right direction, but HonoX is still alpha and minor versions can break. For production today: Hono for the API + a separate frontend, and track HonoX until it stabilizes.

This post belongs to the cluster on architecture running at the edge: read Edge AI & Computer Vision in operations for the hardware/AI angle, or Supply chain Big Data with 100M+ records for the large-data architecture angle. If your business is weighing an edge API layer or an infrastructure rebuild, see the project stories or get in touch.