Hono runs unmodified on Cloudflare Workers, Vercel Edge Functions, Deno, Bun, and Node.js, and that portability isn't an accident — it's built entirely on Web Standard APIs instead of Node-specific ones.
Hono is a small, fast web framework that uses the standard Request/Response objects from the Fetch API instead of Node's http module primitives, which is what makes it runtime-agnostic. Express and Fastify are built around Node's IncomingMessage/ServerResponse, which don't exist in edge runtimes — Hono sidesteps that entirely, making it the natural choice once you're deploying anywhere other than a traditional Node server.
Why Hono Matters (and When to Skip It)
Edge runtimes (Cloudflare Workers, Vercel Edge) don't run Node.js — they run a V8 isolate with Web Standard APIs only, no fs, no Node's http module. Frameworks built on Node primitives simply can't run there. Hono was designed from the ground up around what edge runtimes actually support, and it happens to also run great on Node and Bun.
Skip Hono if you need deep Node.js ecosystem compatibility — some Node-specific libraries (certain database drivers, native modules) don't work in edge runtimes regardless of which framework you use, since the limitation is the runtime, not the framework.
Getting Started with Hono
The API will look familiar if you've used Express, with a few naming differences:
import { Hono } from "hono";
import { cors } from "hono/cors";
const app = new Hono();
app.use("/api/*", cors());
app.get("/health", (c) => c.json({ status: "ok" }));
app.post("/users", async (c) => {
const body = await c.req.json();
const user = await db.users.create(body);
return c.json(user, 201);
});
export default app; // deploys directly to Cloudflare Workers, Vercel, Bun, or Node
The Context object (c) wraps request/response helpers — c.req.json(), c.json(), c.header() — as a thin, runtime-agnostic layer over the underlying Fetch API primitives.
Core Hono Concepts Every Developer Should Know
Built-in Zod validation via @hono/zod-validator gives you the same schema-first workflow Fastify offers, but portable across runtimes:
import { zValidator } from "@hono/zod-validator";
import { z } from "zod";
const userSchema = z.object({
email: z.string().email(),
name: z.string().min(1),
});
app.post("/users", zValidator("json", userSchema), async (c) => {
const data = c.req.valid("json"); // fully typed from the Zod schema
const user = await db.users.create(data);
return c.json(user, 201);
});
RPC-style type sharing between client and server is a standout Hono feature — exporting the app's type lets a frontend get fully typed API calls without codegen:
// server
const routes = app.post("/users", zValidator("json", userSchema), handler);
export type AppType = typeof routes;
// client
import { hc } from "hono/client";
const client = hc<AppType>("https://api.example.com");
const res = await client.users.$post({ json: { email: "a@b.com", name: "A" } }); // typed
Middleware composes with app.use(), same mental model as Express, but implemented against the Fetch Request/Response contract rather than Node streams — this is what lets the same middleware run in a Cloudflare Worker or a Node process without modification.
Common Hono Mistakes and How to Fix Them
Mistake 1: assuming all Node middleware works. Middleware built against Express's req/res objects doesn't work in Hono — the object shapes are fundamentally different. Fix: use Hono's own middleware ecosystem (hono/cors, hono/jwt, hono/logger) rather than porting Express middleware directly.
Mistake 2: relying on Node-only APIs inside an edge deployment. Code that imports fs or Node's crypto module fails at runtime on Cloudflare Workers, even though it compiles fine locally on Node. Fix: check your deployment target's supported APIs before adding a dependency, and prefer Web Standard equivalents (crypto.subtle instead of Node's crypto).
Mistake 3: not using the RPC type-sharing feature. Teams often set up a separate OpenAPI codegen pipeline out of habit, missing that Hono's built-in hc<AppType>() client gives the same type safety with zero extra tooling for TypeScript monorepos.
When Should You Use Hono Instead of Express or Fastify?
Use Hono when deploying to edge runtimes, or when you want one framework that runs identically across Node, Bun, Deno, and edge without rewrites. Stick with Express or Fastify for traditional long-running Node servers where edge portability isn't a requirement and you want their larger, more mature middleware ecosystems.
Hono in Production
If you're building a full-stack TypeScript app with a Hono backend, the RPC client is worth structuring your project around — it removes an entire class of API contract drift bugs between frontend and backend. For edge deployments specifically, keep an eye on cold-start-sensitive dependencies; Hono's own overhead is minimal, but a heavy dependency can still dominate cold start time regardless of framework.
If you're deploying anywhere other than a dedicated Node server, start with Hono instead of porting an Express app later — the migration cost of switching frameworks after the fact is higher than starting with the runtime-agnostic option.