schedule10 мин чтения

Hono вырос с 1,5 млн до 57 млн еженедельных загрузок npm за год. Вот почему.

Еженедельные загрузки Hono на npm выросли ~в 39 раз за 12 месяцев — с 1,5 млн до 57,5 млн. История релизов объясняет почему: упорная работа над производительностью, портируемость «написал один раз — работает везде» и эпоха AI-агентов, сделавшая Hono стандартом по умолчанию.

translate
Доступно на:
infoЭта статья переведена с помощью ИИ

Год назад Hono был нишевым фреймворком для энтузиастов Cloudflare Workers. На прошлой неделе его скачали 57,5 миллиона раз.

Неделя 4 августа 2025 года: 1,47 млн загрузок. Неделя до 4 августа 2026 года: 57,5 млн. Это примерно 39-кратный рост за 12 месяцев — и ускорение продолжает нарастать.

Эту цифру цитируют все. Почти никто не объясняет, почему так вышло. Поэтому я прочитал историю релизов Hono за последний год (releases) и собрал данные npm. Рост не был случайностью. Это серия осознанных решений, которые сработали в нужный момент с эффектом сложных процентов.

graph LR
  A["Авг 2025: 1,5 млн / неделя"] --> B["Ноя 2025: 7 млн / неделя"]
  B --> C["Фев 2026: 27 млн / неделя"]
  C --> D["Май 2026: 45 млн / неделя"]
  D --> E["Авг 2026: 57,5 млн / неделя"]
  E --> F["Кривая всё ещё крутая"]

Форма кривой

Публичный API npm даёт реальные цифры:

Период Загрузок в неделю (прибл.) Рост
Авг 2025 1,5 млн база
Авг–Окт 2025 2,0 млн стабильно
Ноя 2025 – Янв 2026 7,0 млн ~3,5x
Фев–Апр 2026 27,5 млн ещё ~4x
Май–Июл 2026 44,7 млн ~1,6x
29 июля – 4 авг 2026 57,5 млн ускорение продолжается

Интересно не итоговое число, а то, что кривая ускорялась. Просто популярный фреймворк растёт линейно вместе с принятием. Загрузки Hono росли экспоненциально. Что-то давало эффект сложных процентов — и значительная часть этого «что-то» в том, что Hono стал выводом по умолчанию для AI-агентов, пишущих код.


Причина 1: Производительность — это продукт

Прокрутите релиз-ноуты Hono — и каждые несколько недель вы увидите одну и ту же тему: производительность.

  • v4.12.0 — переписанный TrieRouter, в 1,5–2,0 раза быстрее на Node.js, Deno и Bun. c.json() получил быстрый путь как у c.text(): +3,2% запросов/сек и +10,6% пропускной способности от одного этого изменения.
  • v4.13.0 — ещё одна порция низкоуровневых оптимизаций: пропуск аллокаций Headers, замена regex-тестов на indexOf, ленивая аллокация состояния. До 1,25x быстрее на основном пути запрос/ответ.

Эти цифры выглядят как микро-бенчмарки, пока не вспомнишь, где живёт Hono. На Cloudflare Workers, на serverless-функциях, на Bun — вы платите за каждую миллисекунду CPU и за каждый запрос. Фреймворк, который срезает 25% с горячего пути, — это фреймворк, который заметно сокращает чей-то счёт за инфраструктуру. Hono относится к производительности как к продукту, и история релизов это доказывает: команда мейнтейнеров продолжает ускорять ядро, а не просто добавлять фичи.


Причина 2: Написал один раз — работает на любом рантайме

Изначальный повод существования Hono — Cloudflare Workers. Но фреймворк тихо добавлял адаптеры, пока не стал самым портируемым TypeScript-веб-фреймворком на рынке. Один и тот же код работает на:

  • 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 getConnInfo() появился и для AWS Lambda, Cloudflare Pages и Netlify — так что метаданные соединения (IP-адрес для рейт-лимитов и гео-логики) тоже работают везде одинаково.

Это по-настоящему редкое свойство. Большинство фреймворков написаны под один рантайм, а для остальных требуют неловких адаптеров. Hono поставляется как единый пакет без зависимостей, который просто экспонирует fetch-обработчик — а это знает нативно каждый современный рантайм. Когда команды начали деплоить на edge и поддерживать несколько платформ, Hono стал той кодовой базой, которую можно написать один раз и переносить куда угодно. Это огромный драйвер принятия: это не «ещё один фреймворк для изучения», а «фреймворк, который снимает решение о lock-in».


Причина 3: Петля обратной связи AI-агентов

Это та часть, которая объясняет хоккейную клюшку 2025→2026, и это причина, по которой я перевёл бэкенд QuotyAI на Bun + Hono (Почему я выбрал Bun и Hono).

В эпоху AI-агентов самое важное свойство фреймворка — что выдаёт агент. Я уже писал об этом (vibe coding vs open source): математика «строить vs. подключать» перевернулась. Когда код пишет агент, шаблонный код не просто раздражает — он дорогой, потому что каждая строка, сгенерированная агентом, может быть тонко неправильной, а за уборку вы платите в любом случае.

Hono по сути анти-шаблонный:

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)
})

Никаких декораторов. Никаких DTO-классов. Никаких каркасов из модулей, провайдеров и контроллеров. Маршруты — это функции. Валидация собирается в строку-другую. AI-агенты генерируют чистый код, который компилируется с первой попытки, — по моей оценке, на 30–50% меньше шаблонного кода, чем для NestJS или .NET, на тот же эндпоинт (Hono + Bun для AI-платформ).

Теперь умножьте это на число разработчиков, которые в 2026 году практикуют vibe-coding. Каждый из них просит агента построить API, агент берёт Hono, потому что он маленький и предсказуемый, — и на следующей неделе загрузки Hono снова подрастают. Фреймворк стал популярен не только у людей. Он стал популярен у машин, которые генерируют код в масштабе. Вот тот эффект сложных процентов, который виден на графике.


Причина 4: Типобезопасность без церемониала

Второй трюк Hono — сквозная типобезопасность без навязывания какой-либо архитектуры. Релиз-ноуты показывают, как это созревало:

  • v4.11.0hc()-клиент возвращает точные типизированные URL; настраиваемый тип NotFoundResponse.
  • v4.12.0$path() для RPC-клиента; ApplyGlobalResponse, чтобы типы клиента для всех маршрутов знали о ваших глобальных ответах с ошибками.
  • v4.12.x — длинная серия исправлений вывода типов, чтобы цепочки middleware, валидаторы и перегрузки app.on() выводили правильные типы ответов.

На практике: определите маршрут через Zod — и клиент, сгенерированный из типа приложения, точно знает, что возвращает этот эндпоинт: и успех, и ошибку. Это та гарантия, которая раньше требовала тяжёлого фреймворка. Hono даёт её в пакете размером 14KB без единой зависимости. Для соло-фаундеров и небольших команд, которым нужна безопасность без корпоративных лесов, это самое то — и именно поэтому в стеке QuotyAI типизированный контекст Hono используется в 30+ группах маршрутов (Hono + Bun для AI-платформ).


Причина 5: Волна ужесточения безопасности — веха массовости

Читая релизы, я заметил один паттерн: плотная группа релизов безопасности, начинающаяся примерно с января 2026.

  • v4.11.4 — подмена алгоритма JWT (и JWT, и JWK/JWKS теперь требуют явный alg вместо доверия заголовку).
  • v4.11.7 — четыре CVE: обход валидации IPv4 в IP Restriction, кэширование ответов с Cache-Control: private, чтение ключей serve-static на Workers, XSS в ErrorBoundary.
  • v4.12.4 / v4.12.16 / v4.12.18 / v4.12.21 / v4.12.25 / v4.12.27 / v4.12.34 — инъекция полей SSE, инъекция атрибутов cookie, обход body-limit, path traversal в serve-static, кросс-пользовательская утечка кэша, раскрытие данных между запросами в SSR через memo(), ReDoS в CORS и language-middleware и многое другое.

Поток security-объявлений звучит плохо. На самом деле это самое ясное доказательство вехи, которой достиг Hono: его запускает достаточно людей, чтобы стало выгодно атаковать. Здоровая реакция выглядит ровно так, как произошло: быстрые исправления, опубликованные advisories, и дефолты, которые предпочитают явную конфигурацию «работает, но опасно». Каждый такой релиз также запускает новую волну npm install hono от тех, кто следит за обновлениями безопасности. Это укрепляющая петля принятия.


Причина 6: Он перерос «веб-фреймворк»

Hono начинался как роутер. Релизы показывают, как он тихо превращался в full-stack платформу:

  • hono/jsx теперь повторяет поведение React 19 — useRef, изоляция контекста на запрос, безопасность SSR.
  • v4.12.0 добавил SSG-плагин redirectPlugin, генерирующий статические HTML-страницы редиректов.
  • Генерация статических сайтов, middleware для кэширования, рейт-лимитов, secure headers, определения языка, CSRF — каталог встроенных middleware растёт.

Это значит, что Hono конкурирует за нагрузки, которые раньше тянулись к полновесному фреймворку или генератору статических сайтов. Для edge-деплоя — воркера, который обслуживает и сайт, и API из одного кода — Hono теперь заслуживающий доверия единый выбор. Больше нагрузок, которые он умеет обрабатывать, — больше мест, куда его подтягивают.


Машина релизов

Посчитайте релизы с ноября 2025 по август 2026: примерно пятьдесят, включая v4.13.0 от 3 августа 2026 — на той самой неделе, когда был зафиксирован показатель 57,5 млн. Мейнтейнеры релизят постоянно, причём основатель (yusukebe) — самый плодовитый контрибьютор, а растущий пул авторов первого релиза попадает почти в каждый из них.

Постоянный, скучный, предсказуемый релизинг важнее любой отдельной фичи. Фреймворк, который чинит баги за дни и добавляет фичи каждые несколько недель, завоёвывает доверие быстрее, чем тот, что затихает на месяцы. А для AI-агентов фреймворк со свежей документацией и чистым changelog генерирует лучший код. Ритм работает на сложный процент.


Честная оговорка: загрузки ≠ пользователи

Здесь я должен быть аккуратен, потому что не хочу продавать тщеславную метрику.

Счётчики загрузок npm включают CI-пайплайны (каждый прогон тестов переустанавливает), ботов и зеркала и — главное — транзитивные зависимости. Собственная экосистема Hono это усиливает: пакеты вроде @hono/zod-validator, hono-openapi, middleware @hono/* и любые проекты, которые их подключают, сами зависят от hono. Один разработчик, установивший один middleware-пакет, может засчитаться в общую сумму несколько раз.

Поэтому правильное прочтение такое: цифра — это сильная нижняя граница и индикатор направления, а не точное число пользователей. Когда число растёт с 1,5 млн до 57 млн за год, направление однозначно, даже если множитель размыт. Такой крутой реальный рост не бывает случайным.


Что на самом деле означает кривая

Соберите всё вместе — и история напишется сама:

Драйвер Доказательство в истории релизов
Производительность прежде всего v4.12.0 TrieRouter в 1,5–2 раза, v4.13.0 основной путь в 1,25 раза
Портируемость рантаймов Адаптеры для Workers, Bun, Deno, Node, Lambda, Pages, Netlify, Fastly
Дружелюбность к AI-агентам Минимум шаблонного кода, крошечные консистентные паттерны
Типобезопасность без церемониала RPC-клиент $path(), ApplyGlobalResponse, типизированные URL
Массовая безопасность ~15 advisories исправлены за 8 месяцев, явные дефолты аутентификации
Полноценный full-stack hono/jsx, SSG-плагины, 30+ встроенных middleware

Hono выиграл гонку за звание самого быстрого, самого маленького, самого портируемого TypeScript-сервера — и выиграл ровно в тот момент, когда (а) edge/serverless стал целевым деплоем по умолчанию и (б) AI-агенты стали генератором кода по умолчанию. Обе волны вознаграждают одно и то же свойство, вокруг которого построен Hono: меньше кода, быстрее, работает где угодно.

В этом всё объяснение. Цифра 57,5 млн — просто счётчик загрузок. Реальный сигнал в том, что Hono стал дефолтом дефолта — тем, что агенты берут первым, с чего стартуют serverless-туториалы, на что переходят команды, когда хотят перестать думать о своём HTTP-фреймворке.

Я перевёл QuotyAI на него год назад по тем же причинам. Рынок, судя по всему, со мной согласился.


Рекомендуемое чтение


Часто задаваемые вопросы

Почему еженедельные загрузки Hono на npm выросли с 1,5 млн почти до 60 млн? Сочетание факторов: Hono ставит производительность на первое место (v4.12.0 сделал TrieRouter в 1,5–2 раза быстрее, v4.13.0 ускорил основной путь ещё в 1,25 раза), он без изменений работает на Bun, Deno, Cloudflare Workers, Node.js, AWS Lambda и других рантаймах, и он стал фреймворком, на котором AI-агенты генерируют самый чистый код — поэтому эпоха AI-агентов привела Hono в тысячи новых проектов. Постоянный ритм релизов (~50 релизов за 10 месяцев) и волна ужесточения безопасности тоже маркируют и подпитывают массовое принятие.

Означают ли цифры загрузок npm реальное использование? Не напрямую. Загрузки npm включают CI-пайплайны, ботов, зеркала и транзитивные зависимости — экосистема @hono/* и пакеты вроде hono-openapi сами зависят от hono, поэтому одна установка middleware добавляет несколько загрузок к общему числу. Воспринимайте цифру как сильный индикатор тренда и нижнюю границу интереса, а не точное число пользователей.

Что кривая роста говорит об экосистеме? Форма важнее итога. Hono держался на уровне 1,5–2 млн еженедельных загрузок до середины 2025 года, затем утроился к январю 2026-го и продолжил расти — за 27 млн, 44 млн и 57 млн в неделю. Эта хоккейная клюшка совпадает с волной edge/serverless и эпохой AI-агентов, когда быстрый, портируемый TypeScript-фреймворк без лишнего церемониала стал стандартом для генерации новых API.

Почему Hono стал фреймворком по умолчанию для AI-агентов? В Hono почти нет церемониала: маршруты, валидация и OpenAPI в несколько строк, без декораторов и DTO-классов. AI-агенты пишут для Hono на 30–50% меньше шаблонного кода, чем для NestJS или .NET, и сгенерированный код компилируется с первой попытки, потому что паттерны крошечные и консистентные. Когда исправление вывода агента дорого, фреймворк, который минимизирует шаблонный код, побеждает по умолчанию.

Волна исправлений безопасности в последних релизах Hono — это плохой знак? Нет — это признак массового принятия. Когда фреймворк проходит определённый масштаб, он становится привлекательной целью, и здоровая реакция — быстро чинить проблемы. Hono выпускал точечные релизы безопасности (подмена алгоритма JWT, отражение origin в CORS, path traversal в serve-static, утечки кэша, ReDoS) — команда публикует advisory и требует явной конфигурации вместо рискованных значений по умолчанию.


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

Было полезно? Поделитесь.

Похожие статьи

Спасибо за чтение!
Читать другие статьи