Bun vs Node 22 vs Deno: реальные замеры

22 апреля 2026 г. 11K

В 2026 году выбор JS-рантайма перестал быть лотереей. Bun, Node.js 22 и Deno 2 окончательно определили свои ниши, и сравнивать их «вообще» бессмысленно — нужно смотреть на конкретные задачи. Я полгода держала три проекта параллельно: один на Bun, один на Node 22, один на Deno 2. Вот что собрала за этот срок.

Что я мерила

Чтобы не скатиться в синтетические тесты, я выбрала пять прикладных сценариев:

Старт сервера от нуля до первой обработанной HTTP-запроса.
Throughput простого Hono-приложения, отдающего JSON.
Сборка и запуск TypeScript-кода без отдельного компилятора.
Установка зависимостей с lockfile.
Запуск тестового набора с 1500 тестами.

Замеры — на одной машине (16 ядер, 32 ГБ RAM, NVMe), с холодного запуска, среднее по 10 прогонам.

Старт сервера

Hono-приложение с одним маршрутом, читающее env, открывающее БД и слушающее порт.

Bun 1.2: ~38 мс
Deno 2.4: ~62 мс
Node 22 + tsx: ~310 мс

Bun ожидаемо самый быстрый: он сам компилирует TS и не тащит за собой обёртку. Deno конкурирует, потому что у него тоже встроенный TS. Node проигрывает из-за tsx и более тяжёлого процесса.

На холодном старте эта разница важна для serverless-функций (где cold start критичен) и для CLI-утилит. Для долгоживущего сервера разница в 250 мс — мелочи.

Throughput JSON-эндпоинта

Endpoint, отдающий примерно 4 КБ JSON. Тест через k6, 200 одновременных клиентов, 60 секунд.

Bun 1.2: ~141 000 RPS
Node 22 + uWebSockets: ~118 000 RPS
Node 22 + стандартный http: ~83 000 RPS
Deno 2.4: ~94 000 RPS

Bun на встроенном HTTP-сервере выигрывает на голой производительности. Node с uWebSockets подбирается близко, но это уже сторонняя библиотека. Deno стабилен и предсказуем, но чуть медленнее.

На реальном проде разница 20-40% в RPS не всегда критична — обычно бутылочное горлышко в БД, не в рантайме. Но для прокси-сервисов или WebSocket-серверов с миллионом соединений Bun даёт ощутимый выигрыш по железу.

TypeScript без обёрток

Все три рантайма понимают TS из коробки в 2026, но по-разному:

Bun: полноценный, поддерживает tsconfig.json, paths, декораторы.
Deno 2: понимает TS нативно, типы проверяются.
Node 22: с флагом --experimental-strip-types понимает базовый TS, но без проверки типов и без сложных вещей вроде enum'ов и декораторов.

На практике в Node 22 чаще всего ставят tsx для dev и компилируют через tsc для prod. Это рабочий путь, но дополнительные шаги.

Установка зависимостей

Реальный проект на ~600 пакетов, чистая node_modules:

Bun install: ~3.2 секунды
pnpm install (Node): ~14 секунд
npm install (Node): ~28 секунд
Deno install (deno.lock): ~2.8 секунды

Bun и Deno используют параллельную загрузку и кеш на уровне системы. На больших monorepo разница превращается в минуты. Для CI это конкретные деньги.

Тесты

1500 тестов на Vitest:

Bun test (встроенный): ~6.4 секунды
Vitest на Bun: ~5.1 секунды
Vitest на Node 22: ~9.8 секунды
Deno test (встроенный): ~7.2 секунды

Vitest на Bun — самая быстрая комбинация для большинства случаев. Встроенные раннеры в Bun и Deno быстрые, но менее зрелые: некоторые матчеры и моки приходится писать иначе.

Совместимость с Node API

Bun агрессивно поддерживает Node API. По моему опыту, 95% типичных npm-пакетов работает без правок. Исключения — пакеты, которые активно используют worker_threads, специфические части crypto или нестандартные нативные модули.

Deno 2 сильно подтянулся в этом плане после интеграции npm:-импортов. Но всё ещё ставлю Bun впереди по совместимости с экосистемой Node.

Где Node 22 выигрывает

Не в производительности — в стабильности и команде. У Node 22 LTS-статус, сотни продакшен-инсталляций, которые крутятся годами. Любую проблему гуглишь и находишь решение. Любую библиотеку находишь в npm.

Если у тебя проект на 5+ лет с большой командой — Node всё ещё самый осмысленный выбор. Bun быстрее, но риск нарваться на edge-case всегда выше; Deno удобнее, но команда долго привыкает к новой модели.

Где Bun выигрывает

Стартапы и быстрые проекты, где ускорение dev-цикла даёт ощутимую экономию.
Serverless-функции с холодным стартом.
Скрипты и CLI-утилиты — Bun запускает за миллисекунды.
Проекты, где CI-время — деньги (на крупном monorepo экономия в час в день).

Где Deno выигрывает

Проекты с фокусом на безопасность — Deno имеет permissions из коробки.
Edge-deployment в Deno Deploy — нативно.
Простые backend-сервисы без сложной экосистемы.
Проекты, где TS-первый подход критичен.

Скрытые расходы

Bun: иногда падает на странных пакетах. Я держу NODE_DEBUG=1 в CI, чтобы быстрее ловить, какой именно пакет не дружит.

Deno: импорты через npm: работают, но кеш организован иначе, и мониторинг зависимостей сложнее. Если у вас security-аудиты по SBOM — потребуется адаптировать инструменты.

Node 22: всё стандартно, но performance тебя точно не удивит в лучшую сторону. Это «надёжный середняк» — без сюрпризов вверх.

Стратегия выбора, которую я применяю

Стартап / прототип / быстрая разработка → Bun.
Долгоиграющий продукт с большой командой → Node 22.
Edge / serverless / security-чувствительные сервисы → Deno или Bun.
CI-bound monorepo → Bun (минимум по времени установки).

Что я бы делала иначе

На одном проекте мы начали с Node 22 и уперлись в скорость CI. Пробовали ставить Bun только в CI (тесты + lint + build), оставив прод на Node — и это вариант с лучшим соотношением. CI стал быстрее в три раза, прод-стабильность не пострадала. Если страшно сразу прыгать на Bun в проде, попробуйте такой гибрид.

Что копать дальше

Цифры в этом тексте отражают только моё измерение и устареют через полгода. Я бы советовала прогнать собственные бенчмарки на твоём типичном workload и не верить общим обзорам. У каждого рантайма есть сильная и слабая сторона, и иногда разница в архитектуре приложения важнее выбора между ними.