![](https://habrastorage.org/getpro/habr/upload_files/30a/463/08d/30a46308d1442b487ee89896d3d542ba.jpg)
Привет, Хабр! Привет, меня зовут Иван Шурыгин, я работаю fullstack-разработчиком, в свободное время занимаюсь исследованием опенсорс-проектов, люблю покопаться в репозиториях. Таким образом в свое время наткнулся на Node. У меня есть аккаунт на вАЙТИ — если возникнут вопросы по статье, пишите в личку. С радостью отвечу.
Еще в студенчестве, слушая подкасты, я узнал про среду выполнения Bun.js. Тогда она была в бета-стадии и только теоретически подавала надежды на то, чтобы составить конкуренцию Node.js и Deno. Тогда я подумал, что это крутая штука, которая однажды может «выстрелить».
Прошло время, я сменил несколько стеков: успел поразрабатывать на .net, позже стал Java-разработчиком. При этом моя любовь к Node не угасала. А в сентябре 2023 года я понял, что оказался прав в своей вере в Bun.js: она вышла в релиз.
Сегодня я расскажу об этой новой среде выполнения, опишу процесс эволюции рантаймов JavaScript и продемонстрирую производительность Bun в сравнении с Node.js.
Эволюция технологий
Начнем с небольшого экскурса, как комьюнити пришло к Bun.js.
С момента появления JavaScript серверная разработка на JS была практически невозможна, пока в 2009 году Райан Даль, разработчик из Южной Америки, не зарелизил первую версию Node.js. Ему не нравились технологии, которые были на тот момент, — он хотел создать что-то свое. Так Райан пришел к модели, которая сейчас лежит в основе Node.js, — асинхронности и event loop.
Событие стало громким для индустрии, и Node.js быстро начал обрастать своей экосистемой. В 2010 году появился пакетный менеджер, в 2011 году он был импортирован под Windows. Разработчикам понравился Node, и вокруг него начало складываться комьюнити.
Но со временем темпы развития Node.js перестали устраивать разработчиков: новые версии появлялись долго и редко, новых фич практически не было, всё концентрировалось на баг-фиксах. Так в 2014 году появился форк io.js, который развивался только силами комьюнити. Кстати, только благодаря io.js сейчас мы можем пользоваться промисами и async/await.
Разработчиков Node.js это немного отрезвило — они поняли, что нужно что-то менять. В 2015-м они объединяются с io.js, становятся открытой компанией Node Foundation и продолжают разработку в ускоренном темпе. С этого момента модель выпуска версий Node.js меняется, появляется больше новых фич.
Но проблемы всё же остаются — появляется известное выражение «Покажи мне самый большой объект во вселенной, и я покажу тебе свою папку node_modules».
К тому моменту Райан Даль уже отошел от разработки Node.js и долгое время работал над своими проектами. В 2018 году он выступил с докладом «10 вещей, о которых я жалею в Node.js». В конце он представил Deno — духовного наследника Node.js, который должен был закрыть все его недостатки.
Deno был написан на Rust, ориентирован на повышенную безопасность и представлялся как более удобный для разработчиков инструмент. Он поставлялся со своим менеджером пакетов и своим компилятором TypeScript.
В 2021 году начинается разработка героя нашей статьи — Bun. Он быстро прошел стадии альфы и беты, и в 2023 году случился его релиз. Это стало довольно громким событием в комьюнити JavaScript — Bun мгновенно нашел своих поклонников.
Забавный факт: название компании-разработчика — Oven — переводится с английского как «духовка». Соответственно, Bun — это «булочка, испеченная в духовке».
Что умеет Bun?
Рантайм прежде всего ориентирован на быстродействие — возможность встраиваться в ресурсоемкие системы, обрабатывать больше запросов и совершать больше операций в секунду. На этой философии основана вся экосистема Bun, а она, к слову, уже сейчас довольно внушительная. Если уже Deno позиционировался как мультитул со своим компилятором и пакетным менеджером, то Bun получилась еще совершеннее.
Вот основные преимущества Bun.js:
Почти полная совместимость с Node.js/Deno.
В десятки раз быстрее Node.js и Deno.
Нативная поддержка JavaScript.
Богатый набор встроенных Web API.
Самый эффективный менеджер пакетов.
Встроенный dev-сервер.
Встроенный раннер тестов.
Встроенный бандлер.
Возможность почти моментального перехода с Node на Bun.
Откуда такая скорость? В первую очередь это современные технологии и тонны большого труда при профилировке и оптимизации.
За счет чего достигается эффект Blazingly Fast, которым так известен Bun.js сегодня?
Bun написан на языке Zig. Это альтернатива C++ и Rust. Zig предоставляет низкоуровневые возможности для ручной работы с памятью, за счет чего появляется возможность оптимизировать вообще все элементы платформы. К слову, это и было сделано: более 80% составных частей Bun, которые так или иначе уже были реализованы в Node, были переписаны на Zig с максимальной оптимизацией обращений к памяти.
Bun использует движок JSCore. Конечно, напрямую на производительность это не влияет, поскольку многие бенчмарки вам скажут, что JSC почти идентичен по скорости V8. Однако в данном случае дело вовсе не в производительности. JSCore предоставляет более открытую и удобную платформу для выполнения JS-кода, в отличие от V8, который изолирует этот процесс, поэтому накладные расходы на многие процессы снижаются.
Посмотрим на практике
Для начала устанавливаем пакет bloater — это занимает всего 27 секунд. Он не несет какой-либо смысловой нагрузки для проекта — это, по сути, бенчмаркинговый тул, с помощью которого можно протестировать нагрузку и сравнить, как ведет себя пакетный менеджер npm и менеджер Bun.
Открываем две папки для npm и для Bun.
![](https://habrastorage.org/getpro/habr/upload_files/2bf/895/263/2bf895263d2d56a20a91eec916eade37.png)
![](https://habrastorage.org/getpro/habr/upload_files/0df/a16/41b/0dfa1641b5994acfc8f32335bb2ce522.png)
Теперь делаем то же самое для Bun.
![](https://habrastorage.org/getpro/habr/upload_files/e4d/acd/cee/e4dacdcee81fdc06a17373407feede6a.png)
Различия незначительны, но уже здесь мы видим, что Bun требует куда меньшее количество шагов при инициализации проекта, что не может не радовать.
Начинаем наше тестирование. Запускаем сначала процесс для npm.
![](https://habrastorage.org/getpro/habr/upload_files/8f6/427/76e/8f642776e204e61c5432c96f13745796.png)
А перед тем как запустить Bun, я сделаю небольшой пруф его производительности. Мы очистим кеш Bun полностью.
![](https://habrastorage.org/getpro/habr/upload_files/2e5/e0a/7ff/2e5e0a7ff9c5cfb5e9c74c956e9f4f1c.png)
В основе работы npm и пакетного менеджера Bun лежит кеширование. Мы же не будем каждый раз, переустанавливая веб-модули, тянуть из интернета все тонны гигабайтов пакетов, превращая нашу node_modules в черную дыру. Применяются разные техники кеширования, и в основе Bun лежит большое количество этих подходов — наиболее оптимизированные способы копирования.
Единственная проблема, которая может поставить менеджеры npm и Bun рядом друг с другом, — это скорость интернета. Вместо традиционных package-lock Bun использует свои веб-файлы, которые хранятся в бинарном виде и используют большое количество оптимизаций, битовые массивы и так далее. Таким образом, чтение данных происходит быстрее. В нашем случае процесс занял 70 секунд.
![](https://habrastorage.org/getpro/habr/upload_files/03b/78b/a67/03b78ba6788874941b37348e93c94b76.png)
Тем временем npm всё еще в этом состоянии.
![](https://habrastorage.org/getpro/habr/upload_files/ba4/691/9b9/ba46919b98424bc8da12d6cd171193fd.png)
Чтобы удостовериться, что там действительно закачалось такое большое количество данных, вы можете посмотреть на объем папки node_modules — полтора гигабайта.
![](https://habrastorage.org/getpro/habr/upload_files/90a/146/f97/90a146f97aef1c4f9881931fa6062d74.png)
Теперь сделаем следующее. Мы удаляем нашу папку node_modules и устанавливаем пакеты заново.
![](https://habrastorage.org/getpro/habr/upload_files/5b8/981/7d7/5b89817d76613c3e51d32ee65a364f96.png)
Как видите, кеширование сделало свое дело: 6 секунд против 70 в первый раз. На протяжении всего этого времени (более 76 секунд) ситуация в npm не менялась.
![](https://habrastorage.org/getpro/habr/upload_files/252/9f3/ac7/2529f3ac709e97b5c15f9d2676e004bf.png)
Недостатки Bun.js
Самый известный минус этого рантайма — Bun нет на Windows. На мой взгляд, сейчас это не такой серьезный недостаток. Хотя и на Linux Bun не всегда доступен. Но в целом это не проблема, даже для тех, кто предпочитает разрабатывать на Windows, — ведь у нас есть WSL. К тому же процесс разработки не стоит на месте, и команда Oven уже смогла адаптировать сигналы консольного ввода к Bun.
Следующий недостаток — отсутствие менеджера версий. Сейчас это не такая серьезная проблема, но через пару лет может стать более ощутимой. Разработчикам необходима обратная совместимость, а без нее Bun может стать крайне неудобным решением.
Bun еще молодой — большое количество edge-кейсов еще не покрыто. Многие вещи, удачные на первый взгляд, на определенном наборе данных или на каком-то типе процесса могут обернуться для Bun неприятными последствиями. Поэтому мы пока и не слышим о том, что крупные компании стараются писать на Bun свои приложения. Но у этого есть и обратная сторона. Своим выходом Bun спровоцировал определенные изменения, которые коснулись не только сообщества в целом, но и конкретных разработчиков Deno и Node. Например, в 21-й версии Node, которая вышла относительно недавно, появились предпосылки того, что он также начинает наращивать свою производительность во времени. Как мне кажется, это сыграет на руку всем.
Заключение
В том виде, в котором Bun.js есть сейчас, он отлично подойдет разработчикам, которые исследуют различные среды. Даже тем, кто никогда не писал на Node, кто находится на начальной точке старта и хочет погрузиться в разработку, — в Bun всё для этого есть.
Bun.js отлично подойдет стартапам, небольшим компаниям, которые хотят развивать технологии. А вот большим компаниям, которые пишут высокопроизводительные приложения с высокой стабильностью, использование Bun может выйти боком. Дело в том, что Bun.js как платформа развивается очень быстро, и многие изменения в нем могут сказаться на процессе разработки, а для больших вендоров это неприемлемо.
Есть и промежуточная категория, кому Bun.js в теории может подойти, — это компании или пользователи, у которых уже есть приложения на Node, и они хотят повысить их производительность.
Сейчас мы наблюдаем рост конкуренции между Bun, Node и Deno, а конкуренция — это всегда стимул для развития всех игроков рынка. Так что ждем еще большего роста производительности у всех этих продуктов.
вАЙТИ — DIY-медиа для ИТ-специалистов. Делитесь личными историями про решение самых разных ИТ-задач и получайте вознаграждение. |
Комментарии (15)
nikolau
01.04.2024 14:27Забавный факт: название компании-разработчика — Oven — переводится с английского как «духовка». Соответственно, Bun — это «булочка, испеченная в духовке»
Ещё bun in the oven это очень распространенная идиома и тоже кое-что значит)
ponikrf
01.04.2024 14:27Вижу будущее за Bun по многим причинам. В первую очередь потому что его легко деплоить. С нодой все совсем не просто, и даже node distribution не помогает, а наоборот иногда ломает пакеты.
Когда вбиваю в ubuntu apt-get install npm и вижу список зависимостей - плакать хочется. npm работает ну очень медленно.
Видно что развитие идет. Если раньше у меня ничего не запускалось с крашем в sigfault то сейчас постепенно все начинает подниматься.
Удачи проекту
qertis
01.04.2024 14:27+2А я не вижу вау-фичи, ради которой стоит переходить на bun. Ок, мы получили доказательство концепта о необходимости бинарных пакетов для быстрого запуска приложения. Все выиграют, если сотрудники из Node Foundation имплементируют наработки Bun в свою кодовую базу. Такое уже было с теми же package-lock файлами, которые были впервые опробованы в yarn. Теперь очередь за бинарными пакетами, низкоуровневыми оптимизациями на zig и возможность переключиться на JSC в любой момен . Продвигать продукт нуля и делать его мейнстримом у команды энтузиастов вряд ли получится.
MerdedSpade
01.04.2024 14:27Если имплементировать, то это уже не Node.js будет, его надо будет полностью заново реализовывать
Перенести какую то фичу пакетника это не заново создать рантайм на другом движке
bikishov
01.04.2024 14:27Если нужно приложение упаковать в контейнер, то как я понимаю npm будет всё таки лучше?
19Zb84
01.04.2024 14:27+1Не хочу показаться душным, но эта фраза пугает очень сильно.
Самый известный минус этого рантайма — Bun нет на Windows. На мой взгляд, сейчас это не такой серьезный недостаток. Хотя и на Linux Bun не всегда доступен. Но в целом это не проблема,
Где гарантия что bun не начнет каждый месяц выпускать несовместимые обновления и разработка продукта не превратится в переписку по улучшению этого продукта с просроченными сроками по своему проекту ?
venanen
01.04.2024 14:27+4Ему не нравились технологии, которые были на тот момент, — он хотел создать что-то свое. Так Райан пришел к модели, которая сейчас лежит в основе Node.js, — асинхронности и event loop.
Хорошо, что он не захотел что-то свое и не изобрел велосипед. Асинхронность и event loop это базовые принципы JS, которые, разумеется, идут в комплекте с v8.
Событие стало громким для индустрии, и Node.js быстро начал обрастать своей экосистемой. В 2010 году появился пакетный менеджер, в 2011 году он был импортирован под Windows.
Кого импортировали, куда, а главное, откуда?
В десятки раз быстрее Node.js и Deno
Нативная поддержка JavaScript.
Действительно одно из ключевых преимуществ для среды выполнения JS, не поспоришь.
Богатый набор встроенных Web API
Ни в node, ни в bun нет Web API. Потому что это API клиентской части, а bun/node - серверной.
Одним словом, статья про выбор среды для разработки (точнее для интерпретации кода, судя по всему), а по факту - замер в установке пакетов. Ни реальных кейсов разработки, ни особенностей api, ни низкого уровня. Однако, для вайти, где разработка заканчивается установкой пакетов (опционально, замером времени скачивания) - неплохо.
domix32
01.04.2024 14:27Обычно перформанс показывают на всяких npm install vs bun install и оно действительно в десятки раз быстрее для разработчика. Сам код примерно настолько же производителен как у того же V8 и производительность растёт просто из-за уменьшения Memory Footprint. Ну и ко всему часть API у bun ещё пока нетронута и вполне может быть медленее, чем у node/deno. Кажется где-то на хабре была статья со сравнением 1.0 версии.
ALapinskas
01.04.2024 14:27В десятки раз быстрее Node.js и Deno.
Тоже пробовал bun и сравнивал с nodejs, после того как увидел рекламу, что bun якобы быстрее. Собственно, runtime bun может работать и быстрее старых версий ноды, но с версии nodejs@12-14 все преимущество сходит на нет, последние версии ноды уже работают быстрее bun. Поискав по форумам, нашел информацию, что якобы bun быстрее для server-side-rendering приложений, вообщем, какие-то оправдания, которые толком нельзя протестировать. Для себя я сделал вывод, что заявления о более высокой скорости bun, не соответствуют действительности.
Bun написан на языке Zig. Это альтернатива C++ и Rust. Zig предоставляет низкоуровневые возможности для ручной работы с памятью, за счет чего появляется возможность оптимизировать вообще все элементы платформы.
Если хотите увеличить производительность, можно использовать WebAssembly, прекомпиляция и низкоуровневая строгая типизация могут дать понятное преимущество при грамотном использовании, это не какой-то там Zig с помощью которого разработчики bun якобы творят чудеса оптимизации.
domix32
01.04.2024 14:27Это альтернатива C++ и Rust.
Это альтернатив C, все же. Zig слишком прост, чтобы быть на том же уровне что и вышеупомянутые языки и подходы как к управлению памятью, так и структурируванию кода ближе к C или Go.
Самый известный минус этого рантайма — Bun нет на Windows.
буквально на днях вышел 1.1 релиз, где оно теперь и под винду работает. Теперь можно
powershell -c "irm bun.sh/install.ps1 | iex"
и погнали
ooko
01.04.2024 14:27Bun хорош. Но разработку думаю лучше делать на node . Так как если писать под bun то может получится что не будет работать под node. А возможности работать и там и тут очень большой плюс
abutorin
Не хочу показаться "душным", но:
Среда разработки и среда выполнения мне кажется не одним и тем же.
domix32
Это не считая того, что он просто Bun