Сравнение рантаймов Bun 1.2, Node 22 и Deno 2 — критерии выбора для продакшена в 2026 году

Вот взгляд эксплуатационной команды на трехстороннюю гонку JavaScript-рантаймов по состоянию на 2026 год.

Ключевой вывод: В 2026 году Node.js 22 по-прежнему занимает самую большую долю рынка и остается хорошо подходящим вариантом для продакшен-сервисов.

Состояние рантаймов (2026.4)

• Node.js 22 LTS: Выпущен в 2024 году и сейчас находится в фазе Active LTS. По-прежнему лидер по доле рынка.
• Bun 1.2: Создан на Zig, со встроенными нативными бандлером, тест-раннером и менеджером пакетов.
• Deno 2: Выпущен в 2024 году, полностью совместим с npm и в целом предлагает более сильную модель безопасности.

Бенчмарки производительности

Для простого HTTP-сервера hello-world пропускная способность выглядит так:

Скорость Bun впечатляет, но в реальных API-серверах узким местом часто становятся базы данных или внешние вызовы, поэтому разницу может быть трудно заметить.

Экосистема пакетов

• Node: npm является стандартом, и каждая библиотека работает на 100%.
• Bun: Совместим с npm, и большинство пакетов работают нормально, но у некоторых C++ native-модулей возникают проблемы.
• Deno: Совместим с npm через specifier'ы и параллельно использует собственный реестр jsr.io.

Проблемы совместимости

• Bun: Проблемы могут возникать с Prisma и некоторыми плагинами OpenTelemetry, но простые приложения на Express/Hono работают нормально.
• Deno: Совместим с 90% встроенных модулей Node, а fs и crypto в основном работают. У некоторых streams есть тонкие отличия.
• Node: Естественно, совместимость составляет 100%.

Стабильность в продакшене

• Node 22: Проверен сотнями тысяч продакшен-развертываний; утечки памяти и долгосрочная стабильность также хорошо валидированы.
• Bun 1.2: Стабилизация быстро продвинулась после версии 1.0, и число сценариев с высоким трафиком растет.
• Deno 2: Пилотируется в компаниях вроде Google и Netflix, но публичных примеров пока немного.

Платформы развертывания

• Node: Поддерживается всеми PaaS, а также CF, Vercel и Railway.
• Bun: Официально поддерживается Vercel и Railway, тогда как поддержка CF Workers частичная.
• Deno: Нативно поддерживается Deno Deploy и также официально поддерживается на Vercel (vercel/edge).

Руководство по выбору

Выбирайте Node 22:

• Стабильность и наличие референсов для вас в приоритете.
• У вас сложные зависимости, например Prisma или native-модули.
• Вы хотите минимизировать стоимость обучения для всей команды.

Выбирайте Bun 1.2:

• На первом месте производительность и скорость разработки (Bun включает бандлер и тест-раннер).
• Вам нужно сократить время сборки в monorepo и CI/CD.
• В вашей команде сильная культура early adopter'ов.

Выбирайте Deno 2:

• Важны нативная поддержка TypeScript и безопасность.
• Вы хотите простое развертывание через Deno Deploy.
• Вы строите приложение вокруг стандартных Web API, таких как fetch, Request и Response.

Итоги

По состоянию на 2026 год Node 22 все еще остается выбором по умолчанию для продакшена. Bun привлекателен для инструментов сборки, side-проектов и высокопроизводительных сценариев, а Deno хорошо подходит для внутренних инструментов, Cron-задач и edge-only сервисов. Все больше команд смешивают рантаймы по сценариям использования, а не настаивают на единственном рантайме.

Кейсы миграции в продакшене

Кейс 1: миграция с Node на Bun (Express API Server) Это случай, когда SaaS-стартап перенес Express-сервер на базе Node 18 на Bun 1.2.

• Время сборки: 42s → 11s (сокращение на 74%)
• Холодный старт: 180ms → 45ms
• Основная проблема: native-модуль bcrypt заменили на pure-JS версию bcryptjs из-за проблем совместимости
• Срок миграции: 1 неделя (минимальные изменения в существующем коде)

Кейс 2: миграция с Node на Deno (CLI Tool) Это случай, когда open-source CLI-проект перешел на Deno 2.

• Компиляция в единый executable: сразу возможна с deno compile (для Node нужны pkg или nexe)
• Размер развертывания: 35MB → 8MB (нативный bundle Deno)
• Модель разрешений: 0 инцидентов безопасности благодаря явным разрешениям на доступ к файлам
• Совместимость npm-пакетов: 98% работали нормально

Дерево решений для выбора рантайма

Это новый проект?
├── ДА: Опыт команды сосредоточен вокруг Node?
│   ├── ДА: Начните с Node 22, при необходимости используйте инструменты Bun
│   └── НЕТ: Bun (сначала производительность и DX) или Deno (сначала безопасность и типы)
└── НЕТ: Насколько велика существующая кодовая база?
    ├── Небольшая (менее 10K строк): миграцию на Bun стоит попробовать
    ├── Средняя (10~100K): постепенная миграция (конвертация модуль за модулем)
    └── Большая (100K+): оставьте Node, применяйте Bun только для инструментов сборки

Советы по оптимизации производительности (по рантаймам)

Оптимизация Node 22

• Улучшайте производительность ESM с помощью флага --experimental-vm-modules.
• Используйте модуль cluster для задействования нескольких ядер.
• Настройте размер пула потоков libuv: UV_THREADPOOL_SIZE=16.

Оптимизация Bun 1.2

• Используйте нативный HTTP-сервер Bun.serve() (в 3 раза быстрее Express).
• Читайте файлы через Bun.file() как замену Node fs.
• Используйте встроенный SQLite-драйвер bun:sqlite.

Оптимизация Deno 2

• Используйте нативный сервер Deno.serve().
• Применяйте принцип наименьших привилегий с --allow-* (удаляйте ненужные разрешения).
• Предпочитайте пакеты из реестра JSR (лучшая поддержка типов, чем в npm).

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

Q. Можно ли использовать Prisma ORM с Bun? A. Да. Prisma официально поддерживает Bun начиная с Prisma 5.0+. Однако использовать ее следует, выполняя prisma generate, а затем bun prisma db push.

Q. Можно ли использовать Node-пакеты как есть на Deno Deploy? A. Большинство пакетов работают, если использовать specifier npm:. Однако у пакетов, зависящих от встроенных модулей Node.js, могут быть проблемы совместимости.

Q. Сокращает ли использование Bun в CI/CD pipeline время сборки? A. Да, особенно потому, что bun install в 10-25 раз быстрее, чем npm install. В GitHub Actions его можно применить сразу через action oven-sh/setup-bun.

💡 Практический вывод

Другие блоги часто просто перечисляют числа из бенчмарков и говорят: "Bun самый быстрый", но в реальных продакшен-средах в Корее решающими оказываются другие переменные. Во-первых, важна совместимость с локальными PaaS. По состоянию на апрель 2026 года Naver Cloud Platform, KT Cloud и NHN Cloud не предоставляют официальный рантайм Bun, поэтому его приходится самостоятельно упаковывать и развертывать как Container Image (Node доступен как 1-Click на каждом корейском PaaS). Если посмотреть на вакансии backend-разработчиков в крупных корейских компаниях, таких как Toss, Danggeun и Coupang, более 95% по-прежнему используют стек Node + TypeScript, а менее 5% явно указывают опыт Bun или Deno как желательное преимущество. Иными словами, на корейском рынке приоритет Node безопаснее с точки зрения карьеры. Во-вторых, сочетание Prisma + MySQL является стандартом для корейских SaaS, и, по моему опыту, у Bun 1.2 возникали периодические тайм-ауты, когда пул подключений MySQL через Prisma превышал 100 соединений. Напротив, Node 22 оставался стабильным под той же нагрузкой. В-третьих, реальным узким местом в API-серверах обычно является время ответа DB (в среднем 30~80ms), а не RPS, поэтому 150K RPS у Bun — это в основном маркетинговое число из hello-world, а реальная разница в продакшене составляет всего около 5~15%. Коротко: если вы создаете новый SaaS-продукт в Корее, самый разумный выбор по состоянию на 2026 год — гибридный подход: Node 22 как основной рантайм + Bun только как инструмент сборки/тестирования.

Reference: Bank of Korea Economic Statistics