Mateusz: Cześć! Wracamy do Was z nowym odcinkiem podcastu Piwnica IT. Przepraszamy za przerwę, która się pojawiła. Niestety mieliśmy trochę małych przeciwności. Dzisiaj natomiast mamy nadzieję, że temat rozbudzi w Was troszeczkę emocji, tak jak w nas rozbudza. Ponieważ jest to temat, który dość mocno, że tak powiem, ekscytuje naszą społeczność w ostatnich miesiącach w szczególności, bo jest to temat dość przełomowy. W dzisiejszym odcinku porozmawiamy sobie o Bun.js, o tym jak bardzo zmienia świat JavaScriptu, zmienia świat NodeJS. Czy jest i czy może być jakąś sensowną alternatywą w przyszłości, czy nawet obecnie do tego co już mamy? Jest oczywiście ze mną Wojtek. Cześć Wojtku.

Wojtek: Cześć Mateuszu.

Mateusz: Jak się czujesz w tym nowym świecie, który Bun zaczyna wprowadzać?

Wojtek: Myślę, że wygląda on bardzo dobrze. Żałuję trochę, że jesteśmy spóźnieni z nową wersją Bun'a, bo wyszła ona we wrześniu, ale mam nadzieję, że uda nam się to nadrobić i jesteście dalej zainteresowani tym, co Bun ma nam do zaoferowania?

Mateusz: Dokładnie tak. Tym bardziej, że Bun sam z siebie teraz dość dynamicznie się rozwija. I oczywiście pierwsza wersja 1.0, która jest stabilna produkcyjnie wyszła we wrześniu 2023. Natomiast jeżeli spojrzymy w changelog, tam non stop się pojawiają kolejne funkcjonalności i kolejne wersje są dobijane, że tak powiem, do tej wersji 1.0. No i myślę, że jest się czym ekscytować, bo to jest taki duży game changer w porównaniu do tego, co mieliśmy do tej pory. NodeJS, jako runtime Javascriptowy, jest już dość leciwym, że tak powiem, staruszkiem, ponieważ pojawił się w naszym życiu w 2009 roku i od tamtego czasu cały czas był nadbudowywany i nie było dla niego większej konkurencji. I to spowodowało, że w zasadzie powstała nam wielka kobyła, która ma już problemy wydajnościowe od lat i próbuje się zmieniać, ale zmienia się powoli, zmienia i ulepsza się bardzo powoli. Stąd też mieliśmy pierwszą próbę w 2018 roku. Pojawiło się Deno, o którym pewnie porozmawiamy dzisiaj jeszcze. No i mamy rok 2023 i mamy Bun'a, który w zasadzie jako projekt był już rozwijany mniej więcej od 2022 roku. Czym jest Bun? Bun w naszym rozumieniu tak naprawdę oprócz tego, że jest stuprocentowym zastępcą dla Node'a, czyli jest tak naprawdę runtime'm Javascriptowym, może być też, jest też w zasadzie test runnerem, bundlerem, transpilerem, więc tak naprawdę ma w sobie dużo więcej funkcjonalności. Jest takim, że tak powiem, scyzorykiem szwajcarskim, który pozwala nam wrzucić wszystkie narzędzia w jedno miejsce.

Wojtek: Myślę, że to jest właśnie ta unikalna rzecz, która mi się podoba w kontekście Bun'a. Jak sobie przypominam, to nasze środowisko JavaScript'e, które jest dość unikalne, to przerażające jest trochę to, szczególnie dla osób, które wchodzą dopiero do tego środowiska, ile tych rzeczy musi się zadziać po drodze? Ile trzeba mieć jakichś konfiguracji, jakichś rzeczy dodatkowych dookoła tego naszego projektu, żeby w ogóle coś zaczęło działać? Patrząc na takiego React, który jeśli chcemy, żeby było napisane jeszcze w Typescript'cie ilość konfiguracji, translacji i rzeczy, które dzieją się po drodze i tych narzędzi, które musimy skonfigurować jest szczerze powiedziawszy straszna i nie daj Boże, żeby ktoś to robił samemu. I naprawdę podziwiam bardzo tych ludzi, którzy się na tym znają i potrafią to zrobić od początku do końca. Więc dlatego też tak ekscytuje mnie Bun, że będzie to narzędzie, w którym będzie można skonfigurować wszystko i zbudować zarówno serwer, jak i skompilować właśnie powiedzmy aplikację frontendową. Co o tym sądzisz Mateusz? Myślisz, że to fajne?

Mateusz: Zdecydowanie, zdecydowanie taki multitool dla nas jest czymś ekscytującym, bo w zasadzie nie mamy w tym momencie dużych możliwości. No jakby na to nie spojrzeć, większość projektów Javascriptowych to są takie Frankenstein'y, w których nie wiesz, w którym momencie odpadnie Ci jaka część ciała, jeżeli będziesz chciał dokleić coś nowego. Chociażby te problemy z modułami. Część zależności, które chcemy sobie dodawać mają tylko i wyłącznie jedną wersję zależności. Część, czyli tak naprawdę mogą występować tylko w ECMAScript Modules, inne mogą być tylko w CommonJS. Bun to fajnie rozwiązuje, w Node tego nie było. Więc jest kilka takich "ficzerów", o których będziemy wspominać dzisiaj. Natomiast chciałbym, żebyśmy poszli krok dalej, bo tak jak wspomniałem, w 2018 roku już była pierwsza próba tego, żeby zastąpić Node'a pojawił się Deno, czyli lepsza wersja, lepsza wersja Node'a. No ale tak jak rozmawialiśmy zresztą już dzisiaj nie jest tak popularne, jak byśmy zakładali. Nie zaangażował tak bardzo społeczności. Jak myślisz, bo tutaj ja zastanawiam się co było powodem, że Deno jednak nie zaktywizował tych naszych developerów JavaScriptu do tego, żeby przejąć miejsce Node'a, że Node nadal był silny i tak naprawdę Deno tego miejsca tak na gorąco nie zajęło w całości.

Wojtek: Myślę, że był to problem podejścia, a mianowicie tego, że wydaje mi się, że Bun mówi, że to jak pracujemy do tej pory jest ok i ulepszamy to, jak to teraz działa. I tu są narzędzia, które my wam zapewniamy, żeby ta praca była lepsza, szybsza, bardziej wydajna. Gdzie mam wrażenie, że Deno powiedział, że to jak wygląda to teraz jest nie ok. Zmieńmy dużo rzeczy z tym związanych. Nałożyło to też dużą presję, czy też może nie nałożyło dużą presję, ale przyczyniło się do tego, że ten Deno nie był tak mocno zaadaptowany. Chociażby wsparcie dla NPM'a gdzie tak dużo projektów polega na jego wsparciu, gdzie przy Bun możemy po prostu wpisać inną komendę do naszego projektu istniejącego już w Node i to będzie działać. Może nie jeszcze teraz, ale wiem, że taki jest długoterminowy cel. Gdzie w Deno to musieliśmy zmieniać to jak to jest napisane, tak żeby dopasować się do tego jak działa Deno.

Mateusz: Ja myślę, że tutaj mogłoby być problemem też to, że Deno pomimo tego, że chciało zmienić dużo, tak naprawdę dużo nie zmieniało. Chociażby zostawiło sobie silnik JS, który jest pod spodem i w zasadzie Node jest napisany na V8, działa na V8, Deno też działa na V8. Wygląda to trochę tak, jakby próbowano na starym podejściu zrobić coś troszeczkę innego, inaczej podejść po prostu do tego, czym był Node dla większości projektów do tej pory.

Wojtek: Zgadzam się z Tobą Mateuszu i myślę, że te rzeczy, które ułatwiało Deno, tak jak wsparcie Typescriptu out of the box czy to, że mamy top level funkcje asynchroniczne nie dawało aż tyle, dodając jeszcze te zmiany, które musieliśmy wprowadzać, czy też musielibyśmy wprowadzić do naszego projektu, żeby to było warte zmiany.

Mateusz: OK, to w zasadzie wiemy już mniej więcej jak to wyglądało do tej pory, jak to wyglądało z Deno. Wiemy już mniej więcej czym jest Node dla nas i jak to wygląda. No ale pojawił się ten Bun, pojawił się Bun. Tak jak już wiemy Deno i Node są napisane w oparciu o silnik V8 w języku programowania C++. Natomiast Bun podszedł do tematu zupełnie od nowej strony. Zastąpił V8 JavaScript Core. JSC to jest kolejny z silników Javascript'owych, który troszeczkę stawia na szybsze startowanie projektu, zmienia też zarządzanie pamięcią, przez co lepiej optymalizowana jest pamięć. No i to jest w zasadzie silnik, który jest chyba został stworzony bezpośrednio przez Apple'a na rzecz ich przeglądarki Safari, aczkolwiek JSC znajdziemy już w wielu różnych miejscach wykorzystywany. Oprócz tego Bun został napisany w innym języku programowania. Czytałem, że to jest język Zig. Zig jako język niskopoziomowy, który ma zmienić troszeczkę ma być, że tak powiem, następcą języka C, języka C++. Więc już samo podejście do tego, że Bun postanowił wyrównać ten start, zacząć tak naprawdę z nowymi podwalinami, budować na nowym fundamencie sugeruje to, że Bun może byćciekawszy, wiedząc już mniej więcej jak Node funkcjonował przez lata, jakie były jego problemy, jakie były potrzeby. Wydaje mi się, że miał dużo łatwiejsze wejście w to, co może zrobić i jak do tego podejść, ponieważ już miał tą wiedzę o tym, jak ten Node, jak Node był wykorzystywany w produkcji, jak funkcjonował przez ostatnich prawie 15 lat. Więc Bun ma dużo takich funkcjonalności zbudowanych na nowych podwalinach, na nowych fundamentach. I teraz w zasadzie moglibyśmy o tych features Bun'a porozmawiać. Pierwsza rzecz, która się rzuca w oczy to jest to, że Bun jest po prostu szybki. Czyli ten performance.

Wojtek: Tak, chętnie opowiem o performance. Myślę, że jest to ciekawa rzecz. Ciekawe podejście, które Bun zaprezentował. Myślę, że to jest taka rzecz. Jeśli spotykamy się z jakimiś materiałami w Internecie, to pierwsze, co się rzuca w oczy to jest właśnie szybkość Buna. I jest to ciekawa rzecz, jako że zgadzam się w stu procentach, że te, szczególnie w dużych projektach, te rzeczy związane z Node bywają naprawdę wolne. Więc mega fajnie widzieć takie proste porównania pomiędzy Bun'em a Node'm, gdzie Bun wygrywa i to tak znacznie. I myślę, że to podejście o którym, i te decyzje projektowe, o których Ty mówiłeś Mateuszu, czyli zmiana z silnika V8, wykorzystanie Zig'a do zaprogramowania bebechów, że tak powiem kolokwialnie Bun'a, jest super podejściem, bo daje tą szybkość. I każdy z nas dobrze wie jak ta szybkość jest ważna i jak ona się przekłada na taką pracę na co dzień. W momencie kiedy aplikację buduje się przez 10 minut, a buduje się przez 10 sekund ma to ogromny wpływ, przynajmniej, jak u Ciebie Mateuszu, ale jeśli chodzi o moje personalne wrażenia, ogromny wpływ na to, jak ta praca idzie, jaką czerpiemy przyjemność z tej pracy.

Mateusz: Developer Experience przy samym development'cie jest dość istotny i na pewno to, że coś buduje się szybciej sprawia, że chce się po prostu bardziej pracować i chętniej chce nam się pisać. Natomiast Bun też ma ten performance nie tylko z perspektywy samego samego bundlowania czy też budowania naszych projektów. W przykładowej aplikacji czatu, według statystyk policzono, ile wiadomości może być wysłanych na sekundę przez każdy z tych trzech, że tak powiem, runtime'ów. W tym wypadku Node według tego podejścia, miał 179 tysięcy, gdzie Bun mógł wysłać na sekundę prawie milion 100 tysięcy wiadomości. Więc to jest kilkukrotne przebicie tak naprawdę. Gdzieś tu widziałem statystykę, ile request ów HTTP na sekundę może być wykonanych podczas SSR aplikacji React'owej - Bun 67 tysięcy, gdzie w Node było to prawie 14 tysięcy. Więc już sama ta różnica chociażby takich statystyk pokazuje, jak ten performance jest ważny dla zespołu Buna. I tu też warto wspomnieć, że oni starają się, żeby ten performance był ważny na każdym aspekcie, bo tutaj będziemy mówili za chwilę o innych funkcjonalnościach typu wsparcie dla Typescriptu czy np. test runner czy chociażby Hot Module Reloading. To każdy z tych elementów będzie szybszy niż w klasycznym podejściu Node'owym.

Wojtek: Dobrze, że o tym wspominasz Mateuszu. I tak, to prawda, Bun performance zarówno dla developera jak i dla klienta, mówiąc podsumowując i mówiąc trochę oględnie.

Mateusz: Performance to nie wszystko. Tak jak wspominaliśmy, nie tylko wydajność ma znaczenie, ale także inne rzeczy, na które warto zwrócić uwagę. Pierwszą w kolejności, która rzuca się w oczy, to natywne wsparcie dla Typescriptu i wsparcie dla JSXa. Warto tutaj wspomnieć, że w Bun nie musimy dodawać żadnych dodatkowych bibliotek typu ts-node do tego, aby skonfigurować sobie projekt, aby go uruchomić w Typescripcie. Nie będziemy mieć żadnych błędów, ponieważ to będzie działało out of the box. I to chyba jest duży game changer. Co myślisz?

Wojtek: Tak, przynajmniej dla mnie, jeśli chodzi o konfigurację tych wszystkich narzędzi wracamy do tego punktu, o którym mówiłem wcześniej, czyli jeśli chodzi o środowisko JS'owce, w szczególności kiedy dostajemy takiego czystego Node'a, i mamy napisać jakąś prostą aplikację i chcemy, żeby to było w TS'sie. Naprawdę przerażające jest to, jak intymną wiedzę o narzędziach, kompilatorach i translatorach musimy posiadać, żeby to zaczęło działać. I w momencie, kiedy możemy po prostu otworzyć plik czy też utworzyć plik TS, napisać i go odpalić za pomocą jednej komendy - jest to bardzo odświeżające. Jest to super odmiana w porównaniu do tego jak to wygląda teraz.

Mateusz: To prawda, użycie po prostu użycie czegoś bez zastanawiania się nad tym czy to zadziała i czy ewentualnie muszę coś dokonfigurować to chyba jest bardzo duża wartość i chyba każdy developer chciałby mieć takie narzędzie w swojej stajni, które robi za niego wszystkie te takie dodatkowe, że tak powiem, wkurzające konfiguracje.

Wojtek: Tak, szczególnie, że one wynikają właśnie z tego bagażu, który ciągniemy za sobą i dlatego, że to musi działać z jakimiś starymi wersjami API Node'a. Dlatego też to, że możemy się tego wszystkiego pozbyć i to, że to będzie po prostu działać, brzmi naprawdę super.

Mateusz: To prawda. Node wydany w 2009 roku był pisany w czystym JS'ie. Typescript'a jeszcze wtedy nie było. Nikt o nim nie myślał. Tak naprawdę TypeScript stał się standardem dopiero w ostatnich latach, co w zasadzie spowodowało, że dopiero od kilku lat przepisujemy API różnych systemów na TypeScript. I tak jak już wspomniałeś, bagaż przez lata zebrany trudny byłby do zmiany tak od ręki.

Wojtek: To może pogadajmy jeszcze Mateuszu o czymś co nas tyczy w kontekście "ficzerów" dość mocno, jako że oboje programujemy dość dużo w Reakcie, czyli kompilator czy też transpilator JSX?

Mateusz: Na pewno dużą wartością posiadania tego natywnego supportu dla JSX, podobnie jak dla Typescripta będzie to, że nie musisz nic kombinować, po prostu to będzie działało out of the box. Szybkość wczytywania, rozszerzeń plików i transpilacja tego, podobnie jak plików Typescriptowych to jest niesamowita wartość. Sami spotkaliśmy się niejednokrotnie z problemem, że zapomnieliśmy dodać, przynajmniej ja tak miałem w starszych projektach w szczególności, gdzie samodzielnie konfigurowałem sobie środowisko Reactowe, gdzie rzeczywiście trzeba było dodawać Babel, dodawać wszystkie inne transpilery, jakieś dodatkowe flagi, ustawienia presetów, aby to działało. To było tak irytujące czasami. Natomiast tutaj w Bun'ie mamy, mamy to po prostu w gratisie, Bun nam to daje jako prezent. Po prostu chcesz korzystać z naszej funkcjonalności? Proszę bardzo. TypeScript, support dla JSX'a. Chociaż myślę, że warto też zwrócić uwagę na inną funkcjonalność, która jest ważna z perspektywy środowiska JavaScript i która pewnie psuła więcej krwi niż sam TypeScript i konfiguracja jego w projektach w projektach JSowych, a mianowicie mam na myśli tutaj kompatybilność projektu i używanie albo ES Modules, albo używanie standardu Common JS'a? W zasadzie klasycznie było tak, że używaliśmy CommonJS'a i używaliśmy ES Modules na zasadzie takiej, że albo w projekcie mamy ES modules, albo mamy CommonJS. Nie można było wpisywać składni require wziętej z CommonJS'a w tym samym pliku, w którym używaliśmy składni import export z ES Modules. Bun to zmienia. Wprowadza nam możliwość miksowania tego, wprowadza nam możliwość używania jednocześnie dwóch standardów i też dostajemy to out of the box. W Node tego nie było. Spotkałeś się już z trudnościami z tym związanymi?

Wojtek: Spotkałem się. Jest to myślę, że wypadkowa tych rzeczy o których rozmawialiśmy, konfiguracji, transpilatorów itd. Itd. W szczególności też w ostatnich czasach, kiedy to środowisko czysto backendowe, node'owe i środowisko frontendowe, gdzie odchodzimy już od tego modelu SPA, gdzie mamy taki mocny podział tego backendu od frontendu i mamy te technologie, o których rozmawialiśmy w poprzednich odcinkach typu Next, Gatsby, Remix - mieszają nam się te koncepcje, gdzie jesteśmy na backendzie, gdzie jesteśmy na frontendzie. Bardzo szybko możemy trafić na te problemy związane z różnicami w importach, które są mega wkurzające, gdy się z nimi spotka i czasami bardzo ciężko je naprawić. I jest to naprawdę super i myślę, że to właśnie pokazuje tą dobrą drogę w którą zmierza Bun, która bardzo mi się podoba, czyli wsparcie dla tego co już istnieje i rozwiązywanie tych problemów, które mamy, a nie próby nauczenia wszystkich jak to powinno wyglądać od samego początku i mówienia, że ok, te pomysły były niefajne - teraz wszyscy mamy robić tak.

Mateusz: To prawda. Skoro mieliśmy kilka niefajnych pomysłów, to prawdopodobnie projekty już istnieją. Skoro istnieją, to mogą istnieć już od dłuższego czasu i mieć jakiś bagaż doświadczeń ze sobą i kilkaset albo kilka tysięcy linijek kodu już stworzonych.

Wojtek: Zdecydowanie.

Mateusz: Więc czy możemy przenieść projekt Node'a bezpośrednio do Buna, zastąpić Node'a Bun'em?

Wojtek: Kwestia tego czy mówimy na ten moment czy tego jakie są plany. Na ten moment jeszcze nie w 100%, chociaż większość API Node'owych jest wspierana. Można to sobie zobaczyć na oficjalnej dokumentacji Bun'a. Ale myślę, że jeszcze trzeba trochę poczekać. W szczególności jeśli mamy projekt, który korzysta z dużej ilości API Node'owych. Chociaż domyślam się, że w większości wypadków powinno być to na zasadzie plug and play.

Mateusz: Warto też dodać, że Bun zakłada pełną kompatybilność docelowo i już w tym momencie większość prostych tych projektów zadziała - po prostu.

Wojtek: I myślę, że to jest wspaniała rzecz. Nie wiem, czy się ze mną zgadzasz, Mateuszu, ale myślę, że to jest jedna z kluczowych rzeczy, dzięki której Bun wygra i jest duża szansa, że niedługo nie będziemy korzystać z Node'a albo nie w takiej dużej ilości i będziemy korzystać z Buna.

Mateusz: Dość mocna, że tak powiem, sentencja z Twojej strony i założenie, że to się po prostu wydarzy. Jeszcze nie wiemy, on ma dopiero 3 miesiące.

Wojtek: Trochę więcej, ale w tej pełnej wersji 3 miesiące.

Mateusz: Wydaje mi się, że to jest funkcjonalność, która jest dużym game changer'em, bo bez takiej kompatybilności świat IT by tego nie dotknął, bo nikt nie zaryzykuje takiej dużej zmiany dla projektów istniejących czy utrzymywanych od lat. Czymś innym byłoby gdybyśmy tworzyli nowe projekty, ale prawda jest taka, że projekty istnieją i trwają przez lata, zanim dojdą do tego schyłku, gdzie będą zastępowane czymś nowym. Widać to chociażby po naszym Node. Widać to po React'cie, po Angular'ze, widać po tych bardziej doświadczonych rozwiązaniach, które są z nami od lat. Nawet jQuery - nikt nie będzie przepisywał jQuery w tym momencie od zera. Wydawane są kolejne wersje, ale gdzieś ten core prawdopodobnie jest cały czas ten sam. Więc dotyczy to w ogóle całej branży, nie tylko frontendu jako takiego. I ta kompatybilność wsteczna jest bardzo istotna i jest dużą wartością w tym wypadku. Więc może masz rację, to może być, że tak powiem, coś, co przeważy szalę i spowoduje, że w porównaniu do Deno Bun'owi się uda. No ale zobaczymy, myślę czas pokaże.

Wojtek: Czas pokaże.

Mateusz: Bun oprócz tego, że ma te funkcjonalności związane z wydajnością, na którą stawiają. Oprócz tego, że ma pełne wsparcie, będzie miał pełne wsparcie dla Node'a. Oprócz tego, że poszedł w kierunku ułatwienia developmentu poprzez chociażby usuwanie takich ograniczeń jak możliwość wykorzystywania wielu systemów modułów w plikach Javascript'owych - jest też bundlerem. Tutaj chyba warto tylko wspomnieć, że jest to fajny, miły dodatek. Warto też chyba wspomnieć o tym, że według statystyk jest szybszy ten bundler niż chociażby Webpack, aczkolwiek dla samego bundlera chyba nikt nie będzie zmieniał, nikt nie będzie zmieniał Node'a.

Wojtek: To prawda, ale myślę, że to jest też unikalna pozycja, w której stawia się Bun. To, że kontrolują, że zmieniając jedno narzędzie zyskujesz w tak wielu miejscach i nie tracisz w żadnych. I że możesz tym jednym narzędziem zastąpić dużo narzędzi, które musisz utrzymywać, które muszą ze sobą współpracować, które czasami nie chcą ze sobą współpracować. Więc myślę, że to jest mega fajne, że Bun wspiera relatywnie dużo rzeczy w porównaniu do Node'a, chociaż i tak go wykorzystujemy w ten sposób na ten moment. Polegamy tylko na jakichś dodatkowych narzędziach. Ale dzięki temu, że Bun będzie wspierał to wszystko, jest to mega fajne, że będziemy mogli go sobie po prostu wrzucić i z niego korzystać w tak wielu miejscach, nie tracąc na niczym, a tylko zyskując. I też myślę, że to stawia developerów Buna w unikalnej sytuacji, gdzie mogą optymalizować te procesy jako całość, a nie jako pojedyncze kawałki.

Mateusz: Dokładnie tak. Tutaj warto też, idąc już dalej, warto też dodać jako kolejną funkcjonalność, którą Bun wprowadza coś, z czym od lat borykał się Node, czyli wprowadzanie, implementowanie różnych Web API do środowiska Node'owego. Chociażby fetch. W Web API fetch istnieje już od dość dawna. W Node'zie tego nie było. Musieliśmy korzystać z zamienników typu biblioteki node-fetch. Podobnie Web Society, obiekty Request, Response. W Node'zie implementacja Web API trwała dość długo. Implementacja nie zawsze kończyła się już po jednej wersji. Na fetch'a czekaliśmy dosyć długi czas zanim wyszedł z tej fazy experimental, chyba dopiero się pojawił w Node'zie 18. Natomiast Bun wprowadza te API. Po pierwsze już natywnie, czyli wrzuca je jako dostępne. Po drugie starają się znowuż położyć duży nacisk na to, żeby były one szybsze i lepsze niż natywne ich odpowiedniki, czyli fetch. W tym przypadku tak jest zaimplementowany, że będzie działał szybciej niż fetch z przeglądarki. OK. Kolejny punkt to Hot Module Reloading. Warto wspomnieć o tym, że Hot Module Reloading w Bunie będzie zachowywał context. Czego z tego co wiem w Node'zie, nie ma. I też warto też wspomnieć o tym, że flaga --watch nadal jest oznaczona jako experimental w Node'zie. Tutaj tych experimentali w Bun'ie mamy zdecydowanie mniej. Chyba w tym miejscu nie mamy nic więcej do dodania do tych ostatnich punktów. Czy Wojtku chciałbyś jednak rozszerzyć Hot Module Reloading albo Web API?

Wojtek: Myślę, że bardzo dobrze opowiedziałeś Mateuszu o tych funkcjonalnościach.

Mateusz: Dobra, to weź na siebie ostatni feature z naszej listy, czyli test runner. Bun jako test runner. Kompatybilność z Jest, to wiemy na pewno. Wiemy, że jest szybszy, to nie ukrywamy. Co możemy powiedzieć na ten temat więcej?

Wojtek: Myślę, że jeśli chodzi o Buna jako test runnera. Znowu wracamy trochę do tego samego, o czym rozmawialiśmy, czyli że jest to świetny dodatek, który pozwala optymalizować cały proces. Świetnie, że to tam jest, bo dzięki temu te wszystkie "ficzery", które są potrzebne przy okazji standardowego procesu developmentu, przez który przechodzi większość produktów, są bardzo ważne: tak jak testy, to o czym wspominaliśmy, WebAPI i tak dalej. Więc cieszę się, że Bun wspiera całościowo te wszystkie procesy. Myślę, że sam Test Runner nie jest jakoś ekscytujący sam w sobie. Oprócz tego,że jest zaimplementowany dobrze, bo wspiera wszystkie istniejące rzeczy.

Mateusz: To jest kolejne narzędzie w naszym zestawie narzędzi, które Bun nam oferuje. Fajne jest to, że daje kompatybilność z tym Jest'em, bo ludzie są jednak przyzwyczajeni do Jest'a, do jego działania i pracy z nim, więc to jest duża wartość. Szybkość uruchamiania testów też jest ważna i ich procesowania. OK, więc te najważniejsze funkcjonalności chyba wspomnieliśmy. Może w następnym punkcie skupimy się nad tym, czy warto czy nie warto przejść - przechodzić powoli na Buna. Wiem jakie jest Twoje zdanie i wydaje mi się, że pewnie zaraz się nim podzielisz. Wydaje mi się, że warto też dodać w tym miejscu, że Bun też ma swoje wady i jedną z takich wad będzie to, że jeszcze nie mamy pełnej kompatybilności i pełnego wsparcia dla Windowsa, o czym też rozmawialiśmy, co w teorii jest rozwijane, ale jest oznaczone jako experimental. No, ale jak jest Twoje zdanie - warto, nie warto? Czy znasz więcej wad, o których warto wspomnieć?

Wojtek: Myślę, że na ten moment warto spróbować. Myślę, że jeszcze nie zmieniałbym wszystkich projektów na Bun'a. Jednak Node mimo tego bagażu, o którym rozmawialiśmy dzisiaj, niesie ze sobą też lata doświadczeń, lata pytań na StackOverflow, lata problemów, z którymi ludzie się spotkali i już je rozwiązali, gdzie Bun to nowa rzecz i myślę, że jeszcze wiele tych problemów będzie się pojawiało, tak jak przy standardowym procesie developmentu tego typu narzędzi. Ale na ten moment wygląda to tak dobrze, że myślę, że naprawdę warto to sprawdzić. Dodatkowo też pojawiają się nowe frameworki związane z Bun'em, które działają praktycznie tylko na nim, więc naprawdę rozwija się to dośćdynamicznie. Nie wiem, może masz inne zdanie Mateuszu. Myślisz, że to jest moje optymistyczne podejście do tego, że ten Bun wygląda tak dobrze i tak przyszłościowo jest przesadzone trochę?

Mateusz: Wygląda fajnie, wygląda bardzo przyszłościowo. Na pewno pokazuje to, że ten świat ma szansę się rozwijać nie tylko z udziałem Node'a. Sami wiemy, że implementowanie nowości w Node trwało lata i tak naprawdę pojawienie się konkurencji wcześniej w postaci Deno powodowało, że Node przyśpieszał implementację pewnych rzeczy, więc wejście na rynek konkurencji w postaci Buna na pewno, jestem tego w 100% pewny, spowoduje, że będziemy mieć fajne widowisko, bo Node tego nie może tak zostawić. Prawdopodobnie nie jest w stanie zmienić wszystkiego. Prawdopodobnie nie będzie w stanie dogonić Bun'a, ale wiele rzeczy usprawni. Warto czy nie warto? Projekt jest młody, projekt dopiero co się tak naprawdę otrząsa na rynku, więc wydaje mi się, że ja bym poczekał. Popróbował, pouczył się i zobaczył co mogę z tym zrobić. Spróbował może na jakiś małych projektach, podobnie jak Ty, aczkolwiek nie jestem przekonany, czy to jest ten moment, żeby pójść w to produkcyjnie już teraz, kiedy projekt ma 3 miesiące od wydania wersji stabilnej produkcyjnej.

Wojtek: Zgadzam się z Tobą. Myślę, że to jeszcze za wcześnie na all in, ale wygląda to naprawdę dobrze.

Mateusz: Wspomniałeś o frameworkach. Pracowałeś z jednym z ElisiaJS, prawda?

Wojtek: Tak jest. ElisiaJS - tak nazywa się ten framework. Bardzo polecam, jeśli ktoś miałby ochotę przetestować sobie pisanie właśnie takiego prostego serwera w Node'zie czy też w Bun'ie już teraz, bo jest to framework stworzony stricte pod Bun'a. Bardzo polecam, bo bardzo przyjemnie się w tym pracowało. Jest to mega miła odmiana w porównaniu do tego bagażu, o którym rozmawialiśmy z Tobą Mateuszu chwilę przed nagraniem, które Express za sobą ciągnie jako taki kontr przykład, czy też kontr framework właśnie do tego frameworku ElisiaJS.

Mateusz: Warto wspomnieć, pamiętać o tym, że Express jest już dość leciwy. Pewnych rzeczy w nim już nie zmienimy. Jaki jest Express każdy widzi, jakie jest wsparcie chociażby dla TypeScript'a w Expressie każdy wie, każdy widzi. ElisiaJS może być czymś ciekawym. Tym bardziej, że rzeczywiście ona jest tworzona bezpośrednio pod Bun'a. A tu też czytałem, że mamy przynajmniej jeszcze jeden framework, na który warto zwrócić uwagę. I to jest Hono, który jest troszeczkę w pewnych metrykach jest troszeczkę wolniejszy, a w pewnych troszeczkę wygrywa. Tutaj w szczególności warto zwrócićuwagę, z tego co czytałem, średnie zużycie pamięci jest niższe o około 10% i średnie zużycie procesora też jest troszeczkę niższe. W pozostałe metryki w zasadzie się nie różnią. Elisja wygrywa ilością wykonywanych requestów na sekundę z tego co czytałem statystyki, które zresztą widzę przed sobą. OK, podsumowując - warto używać Buna w szczególności do tego, żeby pokazać swoje wsparcie dla takich projektów, bo to może być game changer i takie projekty właśnie powinny pojawiać się na rynku, dla których takie aspekty jak chociażby performance, wydajność czy wsparcie, kompatybilność wsteczna dla rzeczy, które już zostały wytworzone są niesamowicie ważne. W moim odczuciu Bun robi świetną robotę i myślę, że może rzeczywiście zagrozić pozycji Node za jakiś czas. Już w tym momencie można odnaleźć wiele artykułów na temat tego, że Bun jest Node killerem. Chociaż patrząc na ikonę Buna - nie jestem w stanie sobie wyobrazić tej bułeczki jako killera, aczkolwiek myślę, że rzeczywiście to może być coś poważnego, coś innego niż mieliśmy z Deno. Zobaczymy, czas pokaże.

Wojtek: Mateuszu, myślę, że nie mam nic do dodania. Świetnie to podsumowałeś. Czas pokaże. Jednym słowem. Zgadzam się z Tobą, jeśli chodzi o wsparcie dla tego typu projektów. Właśnie dzięki temu, że będziemy z nich korzystać, będziemy mogli nauczyć się tych rzeczy, których na których mieliśmy już tyle czasu, żeby nauczyć się w Node - właśnie dlatego, że ludzie z niego korzystają.

Mateusz: Chciałbym tylko dodać na sam koniec, że wszystkie linki do frameworków, do metryk, do narzędzi, o których dzisiaj rozmawialiśmy znajdziecie w opisie dzisiejszego odcinka. Postaramy się, żeby ten opis był trochę bardziej treściwy niż te opisy w poprzednich odcinkach. Mamy nadzieję, że ten odcinek był dla Was ciekawy. Jak zauważyliście, jest troszeczkę krótszy. Troszeczkę inaczej podeszliśmy do konstrukcji. Mamy nowe intro. Paweł dzięki. No i będziemy wdzięczni za udostępnianie, za lajki, polecenia i do zobaczenia w następnym odcinku. Cześć.

Wojtek: Cześć.