schedule11 min read

Hono Grew From 1.5M to 57M Weekly npm Downloads in a Year. Here's Why.

Hono's weekly npm downloads grew ~39x in 12 months — from 1.5M to 57.5M. The release history explains it: relentless performance work, write-once-run-anywhere portability, and the AI-agent era making Hono the default.

translate
Available in:

A year ago Hono was a niche framework for Cloudflare Workers enthusiasts. Last week it was downloaded 57.5 million times.

The week of August 4, 2025: 1.47 million downloads. The week ending August 4, 2026: 57.5 million. That’s roughly 39x growth in 12 months — and the acceleration is still getting steeper.

This is the number everyone quotes. What almost nobody explains is why it happened. So I read the last year of Hono’s release history (releases) and pulled the npm data. The growth wasn’t luck. It was a series of deliberate choices that compounded at exactly the right time.

graph LR
  A["Aug 2025: 1.5M / week"] --> B["Nov 2025: 7M / week"]
  B --> C["Feb 2026: 27M / week"]
  C --> D["May 2026: 45M / week"]
  D --> E["Aug 2026: 57.5M / week"]
  E --> F["The curve is still steep"]

The shape of the curve

npm’s public API gives us the actual numbers:

Period Weekly downloads (approx) Growth
Aug 2025 1.5M baseline
Aug–Oct 2025 2.0M steady
Nov 2025 – Jan 2026 7.0M ~3.5x
Feb–Apr 2026 27.5M ~4x again
May–Jul 2026 44.7M ~1.6x
Jul 29 – Aug 4, 2026 57.5M still accelerating

The interesting part isn’t the total. It’s that the curve accelerated. A framework that’s just popular grows linearly with adoption. Hono’s downloads grew exponentially. Something was compounding — and a big part of that something is that Hono became the default output of AI coding agents.


Reason 1: Performance is the product

Scroll through Hono’s release notes and you see the same theme every few weeks: performance.

  • v4.12.0 — TrieRouter rewritten, 1.5x–2.0x faster across Node.js, Deno, and Bun. c.json() got the same fast path as c.text(): +3.2% req/s and +10.6% throughput on that single change.
  • v4.13.0 — another batch of low-level optimizations: skipping Headers allocations, replacing regex tests with indexOf, lazy state allocation. Up to 1.25x faster on the core request/response path.

Those numbers read like micro-benchmarks until you remember where Hono lives. On Cloudflare Workers, on serverless edge functions, on Bun — you pay per millisecond of CPU and per request. A framework that shaves 25% off the hot path is a framework that measurably cuts someone’s infrastructure bill. Hono treats performance as the product, and the release history proves it: this is a maintainer team that keeps making the core faster instead of just adding features.


Reason 2: Write once, run on every runtime

Hono’s original reason to exist was Cloudflare Workers. But the framework kept quietly adding adapters until it became the most portable TypeScript web framework on the market. The same code runs on:

  • Cloudflare Workers
  • Bun
  • Deno
  • Node.js
  • AWS Lambda (API Gateway v1, v2, ALB, Lattice)
  • Lambda@Edge
  • Cloudflare Pages
  • Netlify
  • Fastly Compute
  • Vercel Edge

v4.12.0 even added getConnInfo() for AWS Lambda, Cloudflare Pages, and Netlify — so connection metadata (the IP, for rate limiting and geo stuff) works identically everywhere too.

This is a genuinely rare property. Most frameworks are written for one runtime and need awkward adapters for everything else. Hono ships as a single zero-dependency package that happens to expose a fetch handler — which every modern runtime speaks natively. As teams deployed to the edge and started supporting multiple platforms, Hono became the one codebase they could write once and move anywhere. That’s a huge adoption driver: it’s not “another framework to learn,” it’s “the framework that removes a lock-in decision.”


Reason 3: The AI-agent feedback loop

This is the part that makes the 2025→2026 hockey stick make sense, and it’s the reason I moved QuotyAI’s backend to Bun + Hono in the first place (Why I Picked Bun and Hono).

In the era of AI coding agents, a framework’s most important property is what the agent produces. I’ve written about this before (vibe coding vs open source): the math on build vs. install has flipped. When an agent writes your code, boilerplate isn’t just annoying — it’s expensive, because every line the agent generates has a chance of being subtly wrong, and you pay for the cleanup either way.

Hono is essentially anti-boilerplate:

const app = new Hono()

app.get('/hello', (c) => c.text('Hello!'))

app.post('/users', async (c) => {
  const user = await c.req.json()
  return c.json(user)
})

No decorators. No DTO classes. No modules, providers, and controllers scaffolding. Routes are functions. Validation composes in a line or two. AI agents produce clean, first-try-compiling code for this shape — I’d estimate 30–50% less boilerplate than NestJS or .NET for the same endpoint (Hono + Bun for AI Platforms).

Now multiply that by the number of developers doing vibe-coding in 2026. Every one of them asks their agent to build an API, the agent reaches for Hono because it’s small and predictable, and the next week Hono’s downloads tick up again. The framework didn’t just get popular with humans. It got popular with machines that generate code at scale. That’s the compounding effect the graph shows.


Reason 4: Type safety without the ceremony

Hono’s other trick is that it gives you end-to-end type safety without forcing an architecture on you. The release notes show this maturing steadily:

  • v4.11.0hc() client returns precise typed URLs; customizable NotFoundResponse type.
  • v4.12.0$path() for the RPC client; ApplyGlobalResponse so every route’s client types know about your global error responses.
  • v4.12.x — a long series of type-inference fixes so middleware chains, validators, and app.on() overloads infer the right response types.

In practice: define a route with Zod, and the client generated from the app type knows exactly what that endpoint returns — success and error. That’s the kind of guarantee that used to require a heavy framework. Hono gives it to you in a 14KB package with zero dependencies. For solo founders and small teams that want safety without the enterprise scaffolding, that’s the sweet spot — and it’s exactly why the QuotyAI stack uses Hono’s typed context across 30+ route groups (Hono + Bun for AI Platforms).


Reason 5: The security-hardening wave is a mainstream milestone

Reading the releases, one pattern jumped out: a dense cluster of security releases starting around January 2026.

  • v4.11.4 — JWT algorithm confusion (both JWT and JWK/JWKS now require an explicit alg, instead of trusting the header).
  • v4.11.7 — four CVEs: IPv4 validation bypass in IP Restriction, cache of Cache-Control: private responses, serve-static key read on Workers, an XSS in ErrorBoundary.
  • v4.12.4 / v4.12.16 / v4.12.18 / v4.12.21 / v4.12.25 / v4.12.27 / v4.12.34 — SSE control-field injection, cookie attribute injection, body-limit bypasses, serve-static path traversal, cross-user cache leakage, memo() SSR cross-request disclosure, ReDoS in CORS and the language middleware, and more.

A flood of security advisories sounds bad. It’s actually the clearest evidence of the milestone Hono hit: enough people run it that it became worth attacking. The healthy response is exactly what happened — fast fixes, published advisories, and defaults that prefer explicit configuration over “works but dangerous.” Every one of those releases also forced a fresh wave of npm install hono from anyone who pays attention to security updates. It’s a reinforcing loop of adoption.


Reason 6: It outgrew ‘web framework’

Hono started as a router. The releases show it quietly becoming a full-stack platform:

  • hono/jsx now tracks React 19 behavior — useRef, context isolation per request, SSR safety.
  • v4.12.0 added an SSG redirectPlugin that generates static HTML redirect pages.
  • Static-site generation, middleware for caching, rate limiting, secure headers, language detection, CSRF — the built-in middleware catalog keeps growing.

That means Hono competes for workloads that used to reach for a full application framework or a static-site generator. For edge deployables — a worker that serves a site and an API from the same code — Hono is now a credible single choice. More workloads it can handle means more places it gets pulled in.


The shipping machine

Count the releases between November 2025 and August 2026: roughly fifty, including v4.13.0 on August 3, 2026 — the same week the 57.5M number was recorded. The maintainers ship constantly, with the founder (yusukebe) as the most prolific contributor and a growing pool of first-time contributors landing in nearly every release.

Constant, boring, predictable shipping matters more than any single feature. A framework that fixes bugs within days and adds features every few weeks builds trust faster than one that goes quiet for months. And for AI agents, a framework with fresh docs and a clean changelog generates better code. Cadence compounds.


The honest caveat: downloads ≠ users

I need to be careful here, because I don’t want to oversell a vanity metric.

npm download counts include CI pipelines (every test run reinstalls), bots and mirrors, and — the big one — transitive dependencies. Hono’s own ecosystem amplifies this: packages like @hono/zod-validator, hono-openapi, @hono/* middleware, and any project that bundles them all depend on hono itself. One developer installing one middleware package can count several times toward the total.

So the correct read is: the number is a strong lower bound and a direction indicator, not an exact user count. When a number goes from 1.5M to 57M in a year, the direction is unambiguous even if the multiplier is fuzzy. Real growth this steep doesn’t happen by accident.


What the curve actually means

Put it together and the story writes itself:

Driver Evidence in the release history
Performance-first v4.12.0 TrieRouter 1.5–2x, v4.13.0 core path 1.25x
Runtime portability Adapters for Workers, Bun, Deno, Node, Lambda, Pages, Netlify, Fastly
AI-agent-friendly Minimal boilerplate, tiny consistent patterns
Type safety, no ceremony RPC client $path(), ApplyGlobalResponse, typed URLs
Mainstream security ~15 advisories fixed in 8 months, explicit-auth defaults
Full-stack ambition hono/jsx, SSG plugins, 30+ built-in middleware

Hono won the race to be the fastest, smallest, most portable TypeScript server — and it won at exactly the moment that (a) edge/serverless became the default deployment target and (b) AI agents became the default code generator. Those two waves both reward the same property Hono built around: less code, moving faster, running anywhere.

That’s the whole explanation. The 57.5M number is just the download counter. The real signal is that Hono became the default default — the thing agents reach for, the thing serverless tutorials start with, the thing teams switch to when they want to stop caring about their HTTP framework.

I moved QuotyAI to it a year ago for the same reasons. The market apparently agreed with me.



Frequently Asked Questions

Why did Hono’s npm downloads grow from 1.5M to almost 60M per week? A combination of factors: Hono is performance-first (v4.12.0 made the TrieRouter 1.5–2x faster, v4.13.0 sped up the core path another 1.25x), it runs unmodified on Bun, Deno, Cloudflare Workers, Node.js, AWS Lambda and more, and it became the framework AI coding agents produce the cleanest code in — so the AI-agent era pulled Hono into thousands of new projects. Constant release cadence (~50 releases in 10 months) and a security-hardening wave also signal and enable mainstream adoption.

Do npm download numbers mean real usage? Not directly. npm downloads include CI pipelines, bots, mirrors, and transitive dependencies — the @hono/* middleware ecosystem and packages like hono-openapi each depend on hono, so one install of a middleware counts toward hono’s total. Treat the number as a strong trend indicator and a lower bound on interest, not an exact user count.

What does the growth curve tell us about the ecosystem? The shape matters more than the total. Hono sat around 1.5M–2M weekly downloads through mid-2025, then tripled by January 2026, then kept climbing past 27M, 44M, and 57M per week. That hockey stick lines up with the edge/serverless wave and the AI-agent era, when a fast, portable, zero-boilerplate TypeScript framework became the default for generating new APIs.

Why did Hono become the default framework for AI coding agents? Hono has almost no ceremony: routes, validation, and OpenAPI in a few lines, no decorators, no DTO classes. AI agents write 30–50% less boilerplate for Hono than for NestJS or .NET, and the code they generate compiles on the first try because the patterns are tiny and consistent. When an agent’s output is expensive to fix, a framework that minimizes boilerplate wins by default.

Is the security fix wave in recent Hono releases a bad sign? No — it’s a sign of mainstream adoption. Once a framework passes a certain scale it becomes an attractive target, and a healthy response is to fix issues quickly. Hono shipped focused security releases (JWT algorithm confusion, CORS credential reflection, serve-static path traversal, cache leaks, ReDoS) and the core team publishes advisories and requires explicit configuration instead of risky defaults.


Tags: hono npm typescript serverless edge-computing cloudflare-workers bun ai-agents open-source web-framework

Found this useful? Share it.

Related articles

Thanks for reading!
Read more articles