Огромная благодарность Джарреду Самнеру за рецензирование этого сообщения. Без его помощи это было бы невозможно.

Bun — это новый амбициозный набор инструментов и среда выполнения JavaScript. Ранние последователи сообщали, что Bun JavaScript невероятно быстр. Настолько быстро, что некоторые рекламировали его как убийцу Node.js. Из любопытства я решил проверить Bun и сравнить его с конкурентами.

Это так быстро, как люди говорят? Насколько он стабилен? Действительно ли это лучше, чем Node? И можно ли использовать его с непрерывной интеграцией?

Что такое Бан?

Bun — новейшее дополнение к семейству JavaScript. Когда он вышел в 2018 году, он произвел фурор, который может соперничать с Deno. Бун занимает промежуточное положение между Node и Deno. Бан, как и Deno, поддерживает TypeScript из коробки и предлагает удобные для разработчиков функции, такие как ожидания верхнего уровня и встроенные веб-API. Но, в отличие от Deno, Bun предназначен для замены Node, Webpack, Babel, Yarn и PostCSS — все в одном аккуратном пакете.

Bun выпущен с лицензией MIT и LGPL2 (из-за JavaScriptCore) и на момент написания находится в версии v0.1.4.

Чем bun отличается от Deno и Node?

Хотя Bun вдохновлен Node и Deno, он также явно пытается улучшить опыт разработки и производительность, предоставляя набор инструментов с батарейками.

Bun JavaScript использует функции Deno, такие как поставка в виде единого двоичного файла и наличие встроенной поддержки TypeScript.

FeatureBunDenoПоддержка TypeScript/TSX/JSXДаДаОдиночный исполняемый файлДаДаВстроенный модуль запуска тестовДа (в разработке)ДаВстроенные веб-API (выборка, WebSocket и т. д.)ДаДаВерхний уровень awaitsДаДаСовместимость с npmДаНетНет совместимостиДаПоддержка Partialtsconfig.jsonДаНетПоддержка WebAssemblyДаНетВстроенный линтер и форматтерНетДаСистема разрешенийНетДаPackage manifest formatpack age.jsonN/AModule Поддержка модулей ES, CommonJSES ModulesLicenseMIT, LGPL2MITJS EngineJavaScriptCoreV8LanguageZig, C++Rust, Tokio

По сравнению с Node, Bun предлагает больше функций, но при этом стремится быть совместимым:

FeatureBunNodenpm-совместимостьДаДаСовместимость узловДа (бета)ДаОдиночный двоичный файлДаНетВстроенный сборщик и транспиляторДаНетВстроенная поддержка TypeScriptДаНетPackage manifest formatpackage.jsonpackage.jsonLockfile formatBinaryJSONNative live-reloadYesNoBuilt-in .env, .toml supportYesNoTop-level AwaitsYesOnly on ES ModulesJS EngineJavaScriptCoreV8 ЯзыкиZig, C++C, C++LicenseMIT, LGPL2MIT , БСД

Однако нахождение в стадии бета-тестирования означает, что у Бана все еще есть некоторые причуды:

  • Документация ограничена, но Bun’s Discord очень активен и является отличным источником знаний.
  • Нет встроенной поддержки Windows (хотя работает с WSL).
  • Bun может зависнуть при установке пакетов, выборка ненадежна, и, хотя со мной этого никогда не случалось, Bun иногда может давать сбои.
  • Bun еще не на 100% совместим с Node. Не каждый пакет npm работает. Экспресс, например, еще не работает.
  • Публикация в реестр npm не работает.
  • Прежде чем API и интерфейс командной строки станут стабильными, произойдут различные критические изменения.

У булочки есть несколько отличительных характеристик качества жизни:

  • Быстрый встроенный модуль sqlite3 (также планируется MySQL и PostgreSQL).
  • Встроенная поддержка .env, .toml и CSS (дополнительные загрузчики не требуются).
  • Встроенная поддержка фреймворка и оптимизация для React и Next.js
  • Встроенный интерфейс внешних функций (FFI) для низкоуровневых вызовов языков с поддержкой ABI, таких как C, Rust или Kotlin.
  • Возможность копировать ошибки как Markdown (для быстрого обмена).

Это действительно так быстро?

Бан родился из-за недовольства Джарреда Самнера скоростью или ее отсутствием в языке: Я был так разочарован тем, насколько медленным все в JavaScript. Я знаю, что JavaScript может быть намного быстрее. Как бывший разработчик внешнего интерфейса в Stripe, Джарред знает, насколько быстрый цикл итераций важен для продуктивности.

Опыт разработчиков имеет значение. В результате скорость Bun не ограничивается более быстрым обслуживанием запросов, чем другие среды выполнения, но также означает, что он быстрее устанавливает пакеты, запускает тесты, связывает и транспилирует.

Давайте проведем несколько тестов, чтобы увидеть, как Бан на самом деле работает.

Тестовая булочка

Домашняя страница Бана сообщает о повышении производительности в 3 и 4 раза по сравнению с Deno и Node. Это впечатляющие цифры, которые я хочу проверить на себе, поэтому давайте проведем несколько тестов по разным категориям:

  • Bun против npm в качестве менеджера пакетов.
  • Bun против npm в качестве исполнителя скриптов.
  • Bun против npm для рабочих процессов CI/CD.
  • Bun vs. Node vs. Deno для копирования больших файлов.
  • Bun, Node и Deno для обслуживания HTTP-запросов.

В этом случае мы собираемся сравнить:

Вот инструменты, которые я использовал для бенчмаркинга:

Здесь вы можете увидеть сценарии, используемые для каждого случая:

TomFern/ бенчмарки-javascript

По возможности я постараюсь сравнить Bun, Deno и Node напрямую. Однако Deno никогда не задумывался как замена Node, поэтому он не сможет участвовать во всех тестах.

Управление пакетами с помощью Bun

В этом первом тесте мы сравним, как работает Bun JavaScript с npm для создания новых проектов. Как вы можете видеть ниже, npm создает пустое приложение React за 49 секунд.

$ time npx create-react-app myapp​Creating a new React app in /code/myapp.​Installing packages. This might take a couple of minutes.Installing react, react-dom, and react-scripts with cra-template...​added 1392 packages in 38s​16.50s user 6.33s system 46% cpu 49.016 total

Bun поставляется с командой bun create, способной делать то же самое:

$ time bun create react myapp
[package.json] Detected React - added "react-refresh"
​
bun install v0.1.4
🔍 Resolving [1/4]
[29.00ms] git
+ [email protected]
+ [email protected]
+ [email protected]
+ [email protected]
+ [email protected]
​
8 packages installed [2.39s]
​
2.48s user 0.30s system 66% cpu 4.160 total

Бану требуется меньше секунды, чтобы завершить настройку. Это значительное улучшение. Но корректно ли это сравнение? При дальнейшем осмотре мы обнаруживаем, что:

  • npm установил 1392 пакета, а размер node_modules составляет 250 МБ.
  • Bun установил только 8 пакетов общим размером 72 МБ.

Здесь мы сравниваем яблоки с апельсинами, потому что стартовый шаблон React Бана тоньше. Удивительно, но его все еще вполне можно использовать для разработки. Я могу запустить bun dev, чтобы немедленно приступить к взлому. Бан также будет автоматически перезагружаться при каждом изменении.

Тем не менее, стартовый React Бана не может создать производственную сборку. Для этого нам нужно добавить react-scripts с:

$ bun add react-scripts -d

Новая зависимость устанавливает еще 1133 пакета, увеличивая размер node_modules до 298 МБ. Теперь мы находимся в лучшем положении для сравнения.

После создания нового приложения 10 раз с каждым инструментом у нас есть некоторые цифры для сравнения.

Все тесты проводились с теплыми кэшами npm и bun, что объясняет, почему во второй раз npm показал себя намного лучше.

В этом тесте Bun JavaScript выглядит неплохо: он как минимум в 6 раз быстрее, чем npm. Однако время от времени Бан зависал (известная проблема). Кроме того, время от времени npm значительно замедлялся. Я не мог определить причину этого.

Добавление и удаление пакетов с помощью Bun и npm

Далее давайте проверим, сколько времени требуется npm и Bun для добавления и удаления пакетов. В качестве испытательного полигона я буду использовать приложение React, созданное с помощью npm.

После удаления и повторного добавления webpack по 10 раз каждым инструментом я получил следующие результаты:

Единственная загвоздка в том, что управление пакетами Bun не на 100% совместимо с npm:

  • Бан использует двоичный файл блокировки вместо package-lock.json. Но он может распечатать файл блокировки JSON, совместимый с Yarn, с bun install -y.
  • Bun не устанавливает одноранговые зависимости по умолчанию, как npm. Таким образом, вы можете получить другой набор пакетов, чем ожидалось, в вашей папке node_modules.

Бан как таскраннер

К сожалению, компонент среды выполнения Бана не реализовал достаточное количество API-интерфейсов Node для выполнения сложных задач, таких как создание проектов React или выполнение сквозных тестов. Тем не менее, есть одна область, в которой Bun может помочь нам прямо сейчас: как замена npm run.

Проблема с npm заключается в том, что для его запуска требуется от 150 до 200 мс. Может показаться, что это не имеет большого значения, но когда вы часто запускаете скрипты, вы можете чувствовать, что четверть секунды постепенно съедает вашу производительность.

У Bun нет этой проблемы с запуском, поэтому тест запуска bun должен быть как минимум на несколько миллисекунд быстрее, чем тест запуска npm. Мы можем подтвердить это, запустив один и тот же набор скриптов 50 раз и усреднив результаты:

Копирование больших файлов

В этом тесте я хочу сравнить, как каждая среда выполнения справляется с копированием больших файлов, что является областью, в которой было затрачено много усилий по оптимизации.

Я скопировал тот же случайно сгенерированный файл размером 1 ГБ с Bun, Deno, Node и cp для теста. После 20 запусков с каждым инструментом результаты были следующими:

Кажется, Бан и Дено работают одинаково хорошо, и оба выигрывают у cp почти на 50%. Node остается далеко позади, так как выполнение одной и той же задачи занимает более чем в 3 раза больше времени.

HTTP Showdown: Bun против Deno против Node

Среда выполнения JavaScript от Bun включает в себя работающий HTTP-сервер, который предоставляет возможность сравнительного анализа для сравнения с Node и Deno. Для теста я буду использовать примеры сценариев Буна для запуска тестов. Буду генерировать и измерять трафик с помощью oha.

Тест запускает 2 миллиона запросов с параллелизмом 50. Во всех случаях была включена поддержка активности HTTP.

Deno работал на 19 % лучше, чем Node, но Bun превзошел конкурентов, работая в два раза быстрее.

Ускорение CI/CD с помощью Bun

Мы подтвердили, что Bun может дать вам преимущество на вашем компьютере для разработки, но имеет ли смысл использовать его для ускорения CI/CD? Это очень важный аспект, потому что скорость вашего конвейера непрерывной интеграции является решающим фактором для быстрого цикла разработки.

Я настроил две ветки на Демонстрационный проект Semaphore’s JavaScript:

  • master запускает все скрипты с помощью npm, как и было задумано изначально.
  • Ветка bun заменяет npm на Bun. Чтобы было ясно, мы используем Bun только как средство запуска задач, а не как среду выполнения. Этапы тестирования и сборки все еще выполняются Node в обоих случаях.

Ускоряет ли Bun конвейеры CI/CD? После запуска обеих ветвей каждые десять минут в течение пяти часов и выбора 33 образцов результаты следующие:

Время выполненияСредний запуск конвейера (33 запуска)npm3 минуты 46 секундBun3 минуты

Экспериментируя с управлением CI/CD с помощью Bun, я узнал несколько вещей:

  • Вместо того, чтобы кэшировать папку node_modules, быстрее сохранить и восстановить глобальный кеш Буна, расположенный по адресу $HOME/.bun/install/cache.
  • Бан поставляется с экспериментальным тестовым раннером, который должен быть намного быстрее, чем Jest. К сожалению, я не смог заставить его работать. Нам придется подождать, пока булочка не выйдет из духовки, чтобы попробовать ее (каламбур).
  • Есть много возможностей для улучшения. Как только среда выполнения Bun сможет заменить Node, скорость CI/CD может резко возрасти.

Заключение

Бан не только быстрый, он чувствуется быстрым. Такое ощущение, что ты можешь сделать что угодно меньше чем за секунду.

Заменит ли Бан Node? Слишком рано говорить. Когда вышел Deno, он, конечно же, не убил Node — но я не думаю, что это было намерением, поскольку он никогда не задумывался как замена Node. Но Bun JavaScript нацелен на совместимость, поэтому у него больше шансов. И, как мы видели, даже на этом раннем этапе это может быть очень мощным инструментом.

Еще раз огромное спасибо Jarred Sumner за помощь в редактировании этой статьи. Bun — очень крутой проект, так что посмотрите его на GitHub и сотрудничайте, если можете.

Первоначально опубликовано на https://semaphoreci.com 11 августа 2022 г.