One framework for the whole JavaScript runtime map
Hono began in December 2021 as a personal side project. At the time, its creator was building applications for Cloudflare Workers and found the framework options lacking. Itty-router was functional but overly minimal; Worktop and Sunder addressed similar needs but with APIs that didn’t feel right. The answer turned out to be building something new for a specific technical reason: a router built on a Trie tree structure, which offers fast lookups for matching HTTP methods and URL paths to handlers.
The result was a Web Standards-based framework that runs across Cloudflare Workers, Deno, Bun, and Node.js. Because each of these runtimes supports Web Standards APIs, the same code runs unchanged across all of them—no external libraries required. A simple src/index.ts demonstrating a basic handler runs identically when deployed with Wrangler on Cloudflare Workers, directly via Deno, or through Bun. The framework’s own test suite exercises the same code paths across these runtimes, making “write once, run anywhere” a practical reality rather than a tagline.
Production users at scale
The framework has grown well beyond its origin as a yak-shaving exercise—a classic case of wanting to build an app and ending up building the tooling for it first. Cloudflare now uses Hono in core products, including the internal Web API for D1, the company’s serverless SQL database. Workers Logs also runs on Hono, with code inherited from Baselime (acquired by Cloudflare in 2024) migrated entirely onto Workers. Hono is embedded in the internals of other Cloudflare offerings too, such as KV and Queues.
A broader survey of production users shows adoption at companies like Unkey, which deploys Hono’s OpenAPI feature on Cloudflare Workers; Nodecraft, OpenStatus, Goens, NOT A HOTEL, CyberAgent, AI shift, Hanabi.rest, and BaseAI. Large developer tooling companies including Prisma, Resend, the Vercel AI SDK, Supabase, and Upstash use Hono in their examples. Several influencers in the JavaScript ecosystem now treat it as a modern alternative to Express.
Opening the framework up to multiple runtimes beyond Cloudflare Workers was deliberate. Since version 2, Hono has supported Deno and Bun, which helped it gain wider adoption. More users means more bug reports and feature feedback, which has driven quality improvements over time.
Write clearer route handlers
The DX difference between vanilla Workers code and Hono becomes visible with anything more complex than a “Hello World” endpoint. A typical Workers example shows primitive JavaScript that is useful for understanding the platform, but adding a JSON endpoint for GET requests to /books quickly requires verbose manual parsing.
With Hono, the same endpoint collapses to a few lines and reads naturally:
app.get('/books', (c) => c.json({ ok: true }))Path parameters follow the same pattern. Where vanilla Workers code requires if statements plus regex to extract a variable segment like /authors/yusuke, Hono’s route definition lets you declare the endpoint directly and read the value via c.req.param(). For a handful of routes this is neat; for applications with many endpoints, it keeps the code maintainable and debugging straightforward.
Hono uses a context model that matches how Workers naturally work with bindings. The context object carries the request, response headers, and any custom variables, and it also exposes platform bindings. A KV namespace declared as MY_KV is accessible through the context with full TypeScript type inference. Anything possible with vanilla Cloudflare Workers code is still possible inside a Hono handler.
Small core, optional additions
The framework keeps a minimal footprint. A “Hello World” app written with the hono/tiny preset bundles to just 12 KB. For comparison, Express reports a bundle size around 579 KB. Hono’s small size comes from relying on the Web Standards APIs baked into modern runtimes and providing only minimal core functions.
Middleware fills the gaps on demand. Basic authentication on a protected path takes only a few declarations with the built-in Basic Auth middleware. The package also ships built-in middleware for Bearer and JWT authentication and CORS configuration. Third-party middleware adds integrations like Clerk or Auth.js for authentication, plus Zod or Valibot for validation. All of these are optional—the bundle size only grows when specific middleware is included.
Helpers also extend the core: a Streaming helper is useful for AI applications. This modular design fits Workers environments especially well, where account plans enforce file size limits on individual Workers.
Composing behavior in layers
The mental model for Hono separates handlers from middleware. Handlers contain the application logic—receiving a request and producing a response. Middleware wraps handlers to intercept both requests and responses, and middleware can be stacked so that execution flows through multiple layers, like peeling an onion.
Writing custom middleware is straightforward because it works with the same context object used in handlers. A custom request logger is a short function that logs and calls next(). Modifying a response requires only setting a header on the context before passing control onward. Even HTMLRewriter from Cloudflare Workers combines cleanly with middleware, letting you mutate HTML tags returned by a handler without cluttering endpoint code. There is little extra to learn: middleware language mirrors handler language.
Typed API definitions, inferred clients
Hono’s type system unlocks an RPC feature that borders on magic. Server-side API specifications can be expressed as TypeScript types; loading those types as generics on the client inlines automatic inference of paths, arguments, and return types.
Consider a blog post creation endpoint that accepts a numeric id and a string title. A Zod schema creates the validation layer:
const schema = z.object({
id: z.number(),
title: z.string(),
})A Hono handler annotated with zValidator('json', schema) accepts a JSON POST request to /posts and responds with a message property. Taking typeof routes yields a type that captures the API specification. Dropping that AppType into a Hono client makes the whole endpoint available with full code completion—the arguments, return type, and URL are inferred.
Because the client and server share types, there’s no need to memorize API docs or keep a hand-written client in sync. Mistakes get eliminated at compile time rather than surface as runtime bugs.
Server-Side JSX Without the Client
Hono ships with its own built-in JSX implementation. Unlike React's, Hono's JSX was designed from the start for server-side rendering only. The motivation was practical: template engines like Handlebars and EJS rely on eval internally, which Cloudflare Workers doesn't support. JSX avoids that problem entirely.
What makes Hono's JSX distinctive is that it treats tags as plain strings. That means you can write code that would look odd in a client-side framework:
console.log((<h1>Hello!</h1>).toString())There's no renderToString() call the way there is with React. To render HTML, you simply return the JSX value directly:
app.get('/', (c) => c.html(<h1>Hello</h1>))Hono also implements Suspense—React's mechanism for showing a fallback UI while an async component loads—without any client-side code. The async components run entirely in a server-only implementation.
Because Hono reuses the standard JSX toolchain, editor autocompletion for tags works as expected. It brings mature front-end tooling to the server side.
Testing Without Booting a Server
Testing in Hono is straightforward because you don't need to start a server to exercise an endpoint. Here's a complete test that checks a GET request to / returns a 200 status:
it('should return 200 response', async () => {
const res = await app.request('/')
expect(res.status).toBe(200)
})
The Web Standard API abstracts away the server layer, which is why Hono's own test suite—about 20,000 lines—is written in this same style with no server running during tests.
Becoming a Full-Stack Framework
Version 4, released in February 2024, pushed Hono beyond the server into full-stack territory. Three features stand out:
- Static site generation
- Client components
- File-based routing
Client components let JSX run in the browser, so pages gain interactivity. Static site generation means content like blog posts can be pre-rendered without being bundled into a single JavaScript file.
An experimental meta-framework called HonoX builds on this. It combines Hono with Vite to provide file-based routing and hydration of client-side components into server-generated HTML. That makes it a practical choice for larger applications targeting Cloudflare Pages or Workers.
There are also plans to use Hono as a base server for existing full-stack frameworks such as Remix and Qwik. Where Next.js grew from the client side with React, Hono is approaching the full stack from the server side outward.
A First Conference and a Name's Origin
In June 2024, the first Hono Conference was held in Tokyo with 100 attendees. The honojs/hono repository on GitHub now counts 200 contributors, with many more across the other Hono-related projects.
The name "Hono" comes from the Japanese word for "炎"—similar in meaning to "flare." Since Hono started as a framework for Cloudflare Workers, keeping the reference to "flare" in the name was deliberate.
If you want to get started, the Hono website covers setup, the GitHub project is open for issues and contributions, and an interview about Hono is available on the Cloudflare Developers YouTube channel.
