Bun – nowy runtime JavaScript, 3x szybszy od Node.js
Dobrych javascriptowych narzędzi nigdy za wiele, prawda? Jakiś czas temu opisywaliśmy dobrze zapowiadające się RedwoodJS, a już mamy do czynienia z kolejnym. I trzeba przyznać, że z niezłymi ambicjami. Bun, bo o tym środowisku mowa, chce bowiem docelowo stanowić alternatywę dla Node.js, jak i Deno, które z kolei promowane było jako… następca Node.js.
Jeszcze więcej JS-owych narzędzi
Kolejne nowe javascriptowe narzędzia rosną zatem jak grzyby na deszczu, ale nie można powiedzieć, aby zbyt często dościgały swoich ambicji. O ile bowiem są wartościowe, przydatne i mają generalnie dobrą recepcję wśród programistów, to stawianie sobie takich celów, jak zastępowanie runetime'ów takich, jak Node.js, który wykorzystywany jest przez w ogóle trudną do oszacowania liczbę ludzi, często okazuje się porywaniem z motyką na księżyc.
Czy tak samo będzie z Bun? A może rzeczywiście tkwi tu potencjał, który być może nie dzisiaj, i nie jutro, ale w dłuższej perspektywie, może sprawić, że będzie to coś stanowiącego jeśli nie zagrożenie, to przynajmniej alternatywę wobec Node.js i wciąż dość niszowego Deno? Wszak już nie takie potęgi upadały, zastępowane stopniowo, lecz systematyczne przez nowocześniejsze narzędzia.
Sprawdźmy zatem, czy Bun wnosi coś więcej, czy raczej stanowi więcej tego samego.
Bun wyprzedza Node.js
Skoro Bun chce konkurować z Nodem, to jasne, że jest to środowisko uruchomieniowe dla JavaScript i TypeSctipt działające po stronie serwera. Według twórców większość kodu została napisana całkowicie od zera w – co będzie miało ważne rezultaty, o czym za chwilę – języku ZIG, o którym kiedyś pisano, że może być alternatywą dla C. To właśnie ZIG-owi Bun ma zawdzięczać swoją wydajność, a to za sprawą kontroli nad pamięcią, jaką język oddał w ręce twórców Buna.
Jak to przekłada się na praktykę? W zapewne starannie wyselekcjonowanych przez rzeczonych twórców bechmarkach Bun osiąga imponujące wyniki. W przykładowym teście renderowania po stronie serwera interfejsu w Reakcie Bun w wersji v0.1.0 (na co w kontekście wyników chyba warto zwrócić uwagę) obsłużył prawie 49 tys. żądań HTTP. W przypadku Node.js było to zaledwie 16,3 tys, a dla Deno – 15,7 tys. Nawet jeśil założymy rzeczoną selekcję zadań, to i tak różnica jest kolosalna – Bun wyprzedził Node.js o trzy długości!
Równie dobrze Bun wypada w teście polegającym na wczytaniu dużej tablicy SQlite – w tym przypadku Bun obsłużył średnio 60,24 zapytań na sekundę, zostawiając w tyle „konkurencję”. Node poszczycić się może obsłużeniem 23,28 zapytań, a Deno niecałymi 10. W haszowaniu (operacje na sekundę) przewaga Bun nad Node nie jest już tak wielka, bo zaledwie dwukrotna – 13 mln do 6,8 mln.
Bun – po prostu diablo szybki
Nie ma się tu co oszukiwać – Bun nie ma wyróżniać się na tle innych środowisk działających po stronie serwera jakimiś innowacjami funkcjonalnymi. Bun ma być po prostu bardzo szybki. Aż trudno uwierzyć, że zasługą osiąganych przez nowy runtime wyników jest wyłącznie zastosowany język ZIG, ale jeśli tak, to twórcy zrobili z niego naprawdę wspaniały użytek.
Oczywiście hasła o całkowitym zastąpieniu Node.js są dziś przesadą, ale Bun może w przyszłości znaleźć szerokie zastosowania wszędzie tam, gdzie priorytetem, nawet kosztem kompromisów na innych polach, jest wydajność. Więcej informacji, kody źródłowe testów i dokumentacja dostępna są na oficjalnej stronie projektu.