«Вбивця» Node.js: чи справді за Bun майбутнє і чи варто його вивчати

Як техлід JS, я не міг пропустити ажіотаж, який спричинив новий JavaScript-фреймворк Bun. Усі відомі IT-блогери висловили свої думки про нову хайпову технологію. 90 % з них винятково позитивні, з акцентом на те, що Bun дає x10 у швидкості. Насправді ж це не зовсім так, і зараз я розповім чому.

Про автора:

Чим обумовлена швидкість Bun

Одразу умовимося, що Bun дійсно швидкий в більшості випадків. Завдяки чому?

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

2. Кешування. Bun, як менеджер пакетів, іноді може проігнорувати останню версію якоїсь бібліотеки: замість того, щоб піти в інтернет та пошукати оновлення, він знайде ту версію, яка була збережена на локальній машині, та використає її.

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

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

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

Все це дає начебто величезний буст перед Node.js за швидкістю — якщо розглядати фреймворк як тренувальний полігон. Але чи спрацює це в реальних умовах? Перевірмо.

Bun.sh vs. Node.js

Ось тут я знайшов реальне порівняння фреймворків:

 

Маємо такі результати:

Що ще не так з Bun (а що — так)

Треба розуміти, що Bun — це комерційний продукт, а Node — open source. Якщо «булочка» не матиме інвестицій, вона закриється.

Крім того, мене бентежить специфічність мови, якою написаний проєкт, — ZIG. Ця мова сама з’явилася тільки у 2016 році й не факт, що зможе конкурувати із C++, якою написаний Node.js.

Скриншоти з Djinni. До речі, вакансій на Bun на платформі теж немає.

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

Однак я можу собі уявити ситуацію, якщо Bun використовуватимуть маленькі проєкти, що робляться силами ентузіастів. Наприклад, це дійсно цікава технологія для власного пет-проєкту. Але моя особиста порада для новачків: не ставте в пріоритет нові технології під час свого навчання. Дуже багато спокус попрацювати з чимось новим, але неможливо бігти за всіма трендами.

Висновок

Дуже приємно мати одразу один інструмент, який в собі закриває рантайм, пакетний менеджер, бандлер і тест-ранер. І пакетний менеджер дійсно виділяється за швидкістю й показує гарні результати. Але, щоб стати вбивцею Node.js, треба пройти перевірку часом — просто швидкості та хайпу буде недостатньо. Також не забуваємо, що ринок інертний і перехід великих проєктів на нову технологію займає дуже багато часу.

Якщо навколо Bun збиратиметься ком’юніті, зокрема розробники, які не тільки вивчатимуть фреймворк самостійно, але й навчатимуть інших, перспективи вирости у щось велике в нього є. Але точно не в найближчий рік-два.