«Убийца» Node.js: действительно ли за Bun будущее и стоит ли его изучать

Как техлид JS, я не мог пропустить ажиотаж, который вызвал новый JavaScript-фреймворк Bun. Все известные IT-блогеры высказали свои мысли о новой хайповой технологии. 90 % из них исключительно положительные, с акцентом на то, что Bun дает x10 в скорости. На самом же деле это не совсем так, и сейчас я расскажу почему.

Об авторе:

Чем обусловлена ​​скорость Bun

Сразу условимся, что Bun действительно быстрый в большинстве случаев. За счет чего?

1. Оптимизация базовых вещей. Главная идея, стоящая за «булочкой», — оптимизация всего что возможно. Использование каждого байта памяти помогает сохранить микросекунды.

2. Кэширование. Bun как менеджер пакетов иногда может проигнорировать последнюю версию какой-то библиотеки: вместо того, чтобы пойти в интернет и поискать обновления, он найдет ту версию, которая была сохранена на локальной машине, и использует ее.

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

3. Нет поддержки старых версий. Node.js с ее многочисленными версиями дает возможность запускать код на множестве машин. Кроме того, благодаря этому стабильность Node на данный момент тоже выше.

4. На сегодня меньше проверок для разных сценариев.

Все это дает вроде бы огромный буст перед Node.js по скорости — если рассматривать фреймворк как тренировочный полигон. Но сработает ли это в реальных условиях? Давайте проверим.

Bun.sh против Node.js

Вот здесь я нашел реальное сравнение фреймворков:

 

Имеем такие результаты:

Что еще не так с Bun (а что — так)

Надо понимать, что Bun — это коммерческий продукт, а Node — open source. Если у «булочки» не будет инвестиций, она закроется.

Кроме того, меня смущает специфичность языка, на котором написан проект, — ZIG. Этот язык сам появился только в 2016 году и не факт, что сможет конкурировать с C++, на котором написан Node.js.

Скриншоты с Djinni. Кстати, вакансий на Bun на платформе тоже нет.

Возвращаясь к багам, существует еще много неготовых решений для Bun, много непокрытых ошибок. И хотя главный разработчик проекта Джарред Саммер (Jarred Summer) постоянно делится новостями разработки в своем Twitter (такая открытая коммуникация — это действительно круто), как СТО, я не мог бы рискнуть и взять в качестве основной технологии для любого сервиса инструмент, который на таком этапе девелопмента.

Тем не менее я могу себе представить ситуацию, если Bun будут использовать маленькие проекты, создаваемые силами энтузиастов. Например, это действительно интересная технология для собственного пет-проекта. Но мой личный совет для новичков: не ставьте в приоритет новые технологии во время своего обучения. Очень много соблазнов поработать с чем-то новым, но невозможно бежать за всеми трендами.

Вывод

Очень приятно иметь сразу один инструмент, закрывающий в себе рантайм, пакетный менеджер, бандлер и тест-раннер. И пакетный менеджер действительно выделяется по скорости и показывает хорошие результаты. Но чтобы стать убийцей Node.js, нужно пройти проверку временем — просто скорости и хайпа будет недостаточно. Также не забываем, что рынок инертен и переход крупных проектов на новую технологию занимает очень много времени.

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