Hono вырос с 1,5 млн до 57 млн еженедельных загрузок npm за год. Вот почему.
Еженедельные загрузки Hono на npm выросли ~в 39 раз за 12 месяцев — с 1,5 млн до 57,5 млн. История релизов объясняет почему: упорная работа над производительностью, портируемость «написал один раз — работает везде» и эпоха AI-агентов, сделавшая Hono стандартом по умолчанию.
Год назад 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.0 —
hc()-клиент возвращает точные типизированные 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 + Bun для AI-платформ: 6 продакшен-паттернов — 6 паттернов из реальной кодовой базы на Hono
- Почему я выбрал Bun и Hono — исходный разбор решения
- Как я управляю продакшен AI-стартапом за $30 в месяц — деплой той же связки
- Перестаньте спрашивать, какая модель умнее: эпоха «достаточно хорошо» — дешёвые и способные компоненты делают непрерывную работу ИИ реальной
Часто задаваемые вопросы
Почему еженедельные загрузки 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
Было полезно? Поделитесь.
Похожие статьи
Hono + Bun для AI-платформ: 6 production-паттернов, которые стоит перенять
Строим AI-платформу на Hono + Bun: 100+ сервисов, SSE-стриминг, изолированное выполнение кода, реалтайм WebSocket. 6 production-паттернов из реального кодовой базы.
Читать статьюПочему я выбрал Bun и Hono для бэкенда QuotyAI
Создавайте более быстрые бэкенды, отказавшись от NestJS в пользу Bun и Hono — идеально для независимых основателей, создающих AI-продукты в 2026 году
Читать статьюПолная наблюдаемость агентов в собственной базе данных с LangChain, LangSmith SDK и DeepAgents
Как отслеживать каждый вызов LLM, вызов инструмента и подагента в LangChain DeepAgents — и хранить всё в собственной MongoDB вместо облака LangSmith.
Читать статью