Hono - Web Framework That Actually Runs Everywhere

![Hono Large Logo](https://hono.dev/images/logo-large.png)

Why Hono Actually Works in Production

I've been shipping JavaScript to production for like 6 years now. Every framework pisses me off somehow. Express is slow as hell and pulls in more deps than a crypto project. Next.js cold starts take forever - I swear it's longer than my coffee break sometimes. Fastify's decent but you're stuck on Node.

Yusuke Wada built Hono in December 2021 because he was tired of frameworks that couldn't run on Cloudflare Workers without some bullshit adapter layer. You can read the full story here.

Your Code Actually Runs Everywhere

Most "universal" frameworks are lying to you. Express doesn't work on Deno. Next.js edge runtime is missing half the Node APIs you actually need.

Hono uses Web Standards APIs - same Request/Response objects from browser dev. Write it once, runs everywhere:

Cloudflare Workers (the real reason this exists)
Deno (because why not)
Bun (when you want speed)
Node.js (for legacy stuff)
AWS Lambda (if you hate money)
Vercel Edge Functions

I've deployed the same Hono app to all these platforms. Same code. No adapter bullshit. Examples are here if you want to see it.

Bundle Size Will Ruin Your Serverless Day

Serverless cold starts will ruin your day. Express is like 579KB before you add anything useful. Hono is 12KB total.

Bundle Size Comparison

On Workers your API responds in 50ms instead of 2 seconds. On Lambda you're not burning money on 500MB RAM for hello world. Read serverless patterns if you want the theory.

Zero Dependencies = Zero Headaches

Hono has zero dependencies. Actually zero. No npm audit warnings every Tuesday. No left-pad bullshit breaking your build.

Routing, middleware, TypeScript types - it's all built in. Install hono, you're done. No dependency tree that looks like spaghetti.

TypeScript Support That Doesn't Make You Cry

TypeScript support doesn't suck. Route params are typed. Request bodies are typed. Context variables are typed. RPC generates types automatically.

Hono TypeScript Support

app.get('/users/:id', (c) => {
  const id = c.req.param('id') // string, not any
  return c.json({ user: { id } })
})

Express types are garbage - everything's any unless you write type guards for 20 lines.

Performance That Actually Matters in Production

Way faster than Express - Hono hits hundreds of thousands req/sec on Workers. Express dies around 15k.

Real companies use this - Cloudflare runs it internally for Workers KV, D1, Queues. Nodecraft uses it for game servers, Unkey for API auth.

Gotcha: Cold starts on Node 18.2 can spike to 200ms - module resolution got fucked. Found out during a demo that froze for 3 seconds while the client stared at me. Use 18.15+ or just use Bun/Deno.

JSX That Actually Just Works

Want server-side rendering? Just write JSX. No webpack, no babel config, no "use client" React bullshit.

const Layout = ({ children }) => (
  <html><body>{children}</body></html>
)

app.get('/', (c) => c.html(<Layout><h1>Works</h1></Layout>))

Learned this at 3am during a deployment - tried Next.js SSR on Workers, spent 4 hours on React hydration mismatches and Warning: Text content did not match errors. Switched to Hono JSX, deployed in 10 minutes.

Hono Quick Development

Current version is stable. 26k GitHub stars and actively maintained. Not a weekend project.

Version gotcha: Check the releases page before deploying. Security fixes drop fast, edge runtimes don't auto-update.

Hono vs The Usual Suspects

Feature	Hono	Express	Fastify	Next.js
Bundle Size	~12KB	579KB+	~200KB	400KB+
TypeScript	Built-in	@types/express is garbage	Pretty good	React-level good
Runtime Support	Workers, Deno, Bun, Node	Node only	Node only	Node + "edge"
Cold Starts	Under 50ms	2+ seconds	~500ms	3+ seconds
Stack Overflow	Growing community	Every answer exists	Decent help	React complexity
Performance	Way faster	~15k req/sec	~45k req/sec	Varies wildly
Dependencies	Zero	npm audit nightmares	Some	React ecosystem
Memory Usage	Minimal	Hungry	Moderate	RAM destroyer

How Hono Actually Works (And Where It Breaks)

Web Standards APIs - The Good and Bad

Hono uses Web Standards APIs - same Request/Response objects from browser code. This is why it works everywhere, but also why some shit breaks. Web API compatibility varies by runtime.

app.get('/api/users', (c) => {
  return c.json({ users: [] }) // Standard Response, works everywhere
})

The good: Your browser dev skills transfer directly. Same request/response objects you already know.

The gotcha: Node packages expecting req.connection or Node internals won't work. Had to rewrite logging middleware when migrating from Express - kept getting ReferenceError: process is not defined on Workers. Spent 3 hours tracking that shit down. Node compat guide helps.

Router Performance - Why It's Actually Fast

Hono has multiple routers, the default RegExpRouter is fast:

RegExpRouter (Default): Compiles routes to regex patterns. Hits 400k+ req/sec.
SmartRouter: Picks the best algorithm based on your routes. Probably overkill.
LinearRouter: Simple array matching. For <20 routes and minimal startup time.
PatternRouter: Uses URLPattern API. Future-proof but slower.

Unless you're doing 100k+ req/sec, just use the default. Never needed to change it.

Middleware That Doesn't Suck

Express middleware runs in a global chain where order matters and debugging sucks. Hono's middleware is context-scoped:

app.use('/admin/*', async (c, next) => {
  const token = c.req.header('authorization')
  if (!token) return c.text('Unauthorized', 401)
  
  const user = await validateToken(token) // This can fail
  c.set('user', user) // TypeScript knows the type
  await next()
})

app.get('/admin/dashboard', (c) => {
  const user = c.get('user') // TypeScript: User | undefined
  return c.json({ message: `Hello ${user.name}` })
})

What's better: Context variables are typed. No more req.user: any from Express.

What breaks: If your auth middleware throws instead of returning an error response, the error boundary catches it. Learned this when our JWT library started throwing instead of returning null - took 2 hours to figure out why auth stopped working after a dependency update. JsonWebTokenError: invalid signature everywhere but no clue why.

Built-in Stuff That Actually Works

JSON parsing is built in and fast. No express.json() needed:

app.post('/api/data', (c) => {
  const body = await c.req.json() // Just works, properly typed
  return c.json({ received: body })
})

File serving works across runtimes with proper headers:

import { serveStatic } from 'hono/cloudflare-workers'

app.use('/static/*', serveStatic({ root: './public' }))

Compression is built in:

import { compress } from 'hono/compress'
app.use('*', compress())

JSX Without the Build Hell

This works without webpack, babel, or any build shit:

const Layout = ({ children }) => (
  <html>
    <head><title>My App</title></head>
    <body>{children}</body>
  </html>
)

app.get('/', (c) => c.html(<Layout><h1>Hello World</h1></Layout>))

The magic: Hono includes its own JSX runtime. No React dependency.

The limitation: It's not React. No hooks, no client hydration. Server-side only.

RPC That Actually Generates Types

The killer feature nobody talks about:

// Server side
const routes = app
  .get('/posts/:id', (c) => {
    const id = c.req.param('id')
    return c.json({ post: { id, title: 'Hello' } })
  })
  .post('/posts', (c) => {
    // ... validation logic
    return c.json({ created: true }, 201)
  })

// Client side - types are generated automatically
import { hc } from 'hono/client'
const client = hc<typeof routes>('http://localhost:3000')

// This is fully typed, including status codes
const response = await client.posts[':id'].$get({ param: { id: '123' } })
const post = await response.json() // TypeScript knows this shape

Why this matters: Full-stack type safety without GraphQL complexity or tRPC overhead.

When it breaks: Complex nested routes with dynamic segments can confuse the type generation. Had to simplify some API paths.

Testing Without Pain

No need to spin up servers for testing:

import { testClient } from 'hono/testing'

test('Creates user', async () => {
  const client = testClient(app)
  const res = await client.users.$post({ json: { name: 'test' } })
  
  expect(res.status).toBe(201)
  const data = await res.json()
  expect(data.created).toBe(true)
})

Tests run fast because there's no TCP overhead. Debugging failed requests sucks since there's no network tab to inspect. Had to add console.log everywhere when a test started failing - basically printf debugging like it's 1995.

Questions Developers Actually Ask

Is this another weekend project or can I bet my job on it?

Current version is stable. Cloudflare uses it internally, companies like Nodecraft and Unkey run production apps on it. 26k GitHub stars and regular releases since December 2021.But it's newer than Express. Fewer Stack Overflow answers when you're debugging at 3am. Smaller community means fewer tutorials. It's stable, but you'll hit undocumented edge cases.

Will migrating from Express break everything?

Probably not. The API is deliberately Express-like:typescript// Expressapp.get('/users/:id', (req, res) => { res.json({ id: req.params.id })})// Hono app.get('/users/:id', (c) => { return c.json({ id: c.req.param('id') })})What stays the same: Route definitions, middleware concepts, basic patterns.What breaks: Node-specific middleware, packages expecting req.connection, custom Express plugins. util.promisify() calls blow up on Workers with TypeError: Cannot read properties of undefined. Budget 2-3 days for migration gotchas on a medium app.

Does it actually work on all these runtimes or is that marketing bullshit?

It works.

I've deployed the same Hono codebase to:

Cloudflare Workers (best performance)
Deno Deploy (easiest deployment)
Node.js (legacy compatibility)
AWS Lambda (expensive but works)Same code, no runtime adapters needed.

Catch: you can't use Node-only packages like fs on edge runtimes.

What happens when I need middleware that doesn't exist yet?

You write it yourself. Hono's middleware ecosystem is smaller than Express's 15-year head start. Upside: built-in middleware covers most common needs (JWT, CORS, compression, validation).Writing custom middleware is straightforward:typescriptconst customAuth = async (c, next) => { const token = c.req.header('authorization') if (!token) return c.text('Unauthorized', 401) // Your auth logic here await next()}

How's the TypeScript experience compared to Express?

Night and day better.

Express with TypeScript is community-maintained garbage:```typescript// Express

types are liesapp.get('/users/:id', (req, res) => { const id = req.params.id // any, not string req.user // Property 'user' does not exist})// Hono
types actually work app.get('/users/:id', (c) => { const id = c.req.param('id') // string, properly typed const user = c.get('user') // User | undefined, typed context})```Hono's RPC feature generates end-to-end types from server to client. No more maintaining separate API type definitions.

Will cold starts actually be faster or is that benchmark bullshit?

Cold starts are faster.

Hono is 12KB vs Express at 579KB. In serverless:

Cloudflare Workers: 50ms vs 2+ seconds
AWS Lambda: 200ms vs 1+ second
Vercel Edge:

Similar improvementsThe benchmarks reflect real deployment performance, not synthetic tests.

Can I use it for server-side rendering without losing my mind?

Yes, but it's not React. Hono's JSX is server-side only:typescriptconst Page = ({ title, children }) => ( <html> <head><title>{title}</title></head> <body>{children}</body> </html>)app.get('/', (c) => c.html(<Page title="Hello">Content</Page>))Pros: No build step, no webpack config, no hydration complexity.Cons: No client-side interactivity, no hooks, no React ecosystem.

What about databases and ORMs?

Use whatever works on your target runtime:

Node.js/Deno: Prisma, Drizzle ORM, raw SQL
Cloudflare Workers: D1 (SQLite), Turso, PlanetScale
Universal: Drizzle ORM works everywhereHono doesn't care about your data layer
it's just a web framework.

How do I debug when things go wrong?

Error handling is solid with app.onError():```typescriptapp.on

Error((err, c) => { console.error('Shit broke:', err) return c.text('Internal Server Error', 500)})```But debugging is harder than Express:

Fewer tutorials online
Edge runtime debugging tools are limited
Stack traces in Workers are cryptic
`TypeError:

Cannot read property 'xyz' of undefined at worker.js:1:1` tells you nothing useful

Should I use this for my next project?

Use Hono if:

You're deploying to Cloudflare Workers or similar edge platforms (this is the main reason)
Bundle size and cold start performance actually matter to your users
You're tired of Express Type

Script being garbage

You're building APIs, not full-stack React appsStick with Express if:
Your team knows Express well and shipping fast matters more than performance
You need that one specific middleware that only exists for Express
You're building traditional server-rendered applications
"It's what we've always used" and your boss won't let you change it

Quick Navigation

Why Hono Actually Works in Production

Your Code Actually Runs Everywhere

Bundle Size Will Ruin Your Serverless Day

Zero Dependencies = Zero Headaches

TypeScript Support That Doesn't Make You Cry

Performance That Actually Matters in Production

JSX That Actually Just Works

Web Standards APIs - The Good and Bad

Router Performance - Why It's Actually Fast

Middleware That Doesn't Suck

Built-in Stuff That Actually Works

JSX Without the Build Hell

RPC That Actually Generates Types

Testing Without Pain

Is this another weekend project or can I bet my job on it?

Will migrating from Express break everything?

Does it actually work on all these runtimes or is that marketing bullshit?

What happens when I need middleware that doesn't exist yet?

How's the TypeScript experience compared to Express?

Will cold starts actually be faster or is that benchmark bullshit?

Can I use it for server-side rendering without losing my mind?

What about databases and ORMs?

How do I debug when things go wrong?

Should I use this for my next project?

Related Tools & Recommendations

Express.js - The Web Framework Nobody Wants to Replace

Hono, Express, Fastify, Koa: Node.js Framework Speed & Selection

Fastify Overview: High-Performance Node.js Web Framework Guide

Koa.js Overview: Async Web Framework & Practical Use Cases

Bun JavaScript Runtime: Fast Node.js Alternative & Easy Install

I Benchmarked Bun vs Node.js vs Deno So You Don't Have To

Hono Performance Optimization: Eliminate Cold Starts & API Lag

Fresh Framework Overview: Zero JS, Deno, Getting Started Guide

Django: Python's Web Framework for Perfectionists

Hono Production Deployment Guide: Best Practices & Monitoring

FastAPI - High-Performance Python API Framework

Actix Web: Rust's Fastest Web Framework for High Performance

Axum Web Framework Overview: Why It's Better & How It Works

Webpack: The Build Tool You'll Love to Hate & Still Use in 2025

Node.js Memory Leaks & Debugging: Stop App Crashes

Qwik Overview: Instant Interactivity with Zero JavaScript Hydration

GraphQL Overview: Why It Exists, Features & Tools Explained

SolidJS: React Performance & Why I Switched | Overview Guide

Bun Production Deployment Guide: Docker, Serverless & Performance

Node.js Production Debugging Guide: Resolve Crashes & Memory Leaks