Tym razem na tapecie temat, który wydawałoby się, nie może być interesujący. Bo czy kolejny bundler dla JavaScriptu może wnieść coś nowego? Ale esbuild jest na swój sposób wyjątkowy, bo jest napisany w Go i rzeczywiście wprowadza nową jakość jeżeli chodzi o czas budowania.

Przydatne Linki

• esbuild - https://github.com/evanw/esbuild

Transkrypt

Marek Piechut: No witam Bartku. To co, może ja zaczynam?

Bartek Witczak: Dzisiaj Twój temat na pierwszy ogień idzie.

Marek Piechut: Mój temat jest taki trochę kontrowersyjny, jeżeli chodzi o moją osobę, bo nigdy bym nie pomyślał, że poruszę taki temat. Ale ten temat to jest nowy bundler do JavaScriptu.

Bartek Witczak: Nie wiem, ile osób Cię zna, ale takiego czegoś, jak kontrowersyjny temat w Twoich ustach…, no dobrze, słucham.

Marek Piechut: Nie no, po prostu, zazwyczaj, wydaje mi się to skrajnie nieinteresująca rzecz, coś takiego jak nowy bundler, bo mam takie wrażenie, że nowe bundlery są takim tworem ludzi, którzy nie mają co robić w weekendy i po prostu, zamiast grać w grę Tomb Raider to robią bundlery.

Bartek Witczak: Bardziej z tego jest nietuzinkowy, że nowy bundler wychodzi, mniej więcej, raz na tydzień.

Marek Piechut: Tak, tak. Jak zwykle takie rzeczy - bardzo potrzebne i niezbędne - rozwiązują straszliwe problemy, nie do rozwiązania inaczej. Ale…, generalnie ten bundler nazywa się Esbuild, dla tych niewtajemniczonych, którzy nie wiedzą, co to jest bundler, no to jest takie narzędzie, które sprawia, że z wielkiej, ogromnej, niespodziewanie ilości różnych plików JavaScriptu, które ściągamy z MPN- a, musimy zbudować sobie w końcu jeden plik JS- a, który będzie wgrzany w stronę. No i bundler, to jest właśnie takie narzędzie, które ni mniej, ni więcej, tylko to dokładnie robi. A dlaczego ten akurat mnie zainteresował, bo tych bundlerów jest ileś tam i one ciągle powstają, ale ten jeden robi coś wyjątkowego, mianowicie w benchmarkach jest 100 razy szybszy niż każdy inny.

Bartek Witczak: To może być ten powód, dla którego będzie warto z niego skorzystać.

Marek Piechut: No właśnie. Jak się zaczyna pracę z frontendowymi projektami to, z reguły, nie jest żaden problem, ale po jakimś czasie, przy większych projektach, to te bildtime’y zaczynają być kosmiczne, że czekasz, na przykład: minutę na produkcyjny bild – to jest strasznie dużo czasu. Albo pierwszy, jak odpalasz sobie projekt do developmentu, to pierwszy bild, ten który jest cały od początku, potrafi potrafi trwać pół minuty, minutę, i tak siedzisz i patrzysz w to.

Bartek Witczak: Dokładnie, szczególnie, że przechodzimy na tą stronę tego liveloud’u i takiego developmentu, który możemy robić od razu. Takie oczekiwanie, to jest coś, jeszcze kiedyś, niespotykanego.

Marek Piechut: Znaczy, no to jest takie dziwne, że człowiek jest przyzwyczajony, że wszystko się dzieje live, a tu proszę to bundlowanie trwa tak długo. No i dlaczego on jest taki szybki, bo większość tych bundlerów jest jednak napisana w JavaScripcie, co bardzo dobrze, bo powinno się jeść swój własny doc food, także to jest też taki bardzo dobry use case do tego, żeby pokazać, że JavaScript się nadaje do różnych rzeczy. A tutaj, ktoś ambitnie napisał go całego w GO i jeszcze z nastawieniem, że będzie ultraszybki, więc wszystkie te rzeczy są na maksa optymalizowane: na maksa są optymalizowane struktury danych, minimalizowana jest ilość przebiegów, i tak dalej. I ten efekt - 100 razy szybciej, to jest, mniej więcej, stała liczba, gdzieś tam w okolicach tych stu razy we wszystkich próbach z TypeScriptem, nie z TypeScriptem. No i, jeszcze w dodatku, z rzeczy, które to obsługuje, to też nie jest taki duży bundler, który robi wszystko, tylko to jest takie bardziej proste narzędzie, ale obsługuje ES 2019/2020, trochę future’ów z ESnext, SOSmapy, tryhacking, bez tego, teraz, już się nie da praktycznie żyć. JSX-a, TypeScript takie rzeczy. Także myślę, że będzie można z nim coś tam robić.

Bartek Witczak: No dobra, ale wydaje Ci się, że właśnie to, że jest napisany w GO i to, że dzięki temu jest taki szybki, ale czy jest w stanie przejść do takiego, powiedzmy, mainstreamu i zastąpić webpacka. Czy jednak, przez to, że, to nie jest takie czyste, js-owe narzędzie, co jakby powoduje, że cały ten contribution opensourcowy nie jest w stanie, tam dopisywać tak łatwo kolejnych elementów do tego, będzie powodował, że i tak wszyscy zostaniemy, w jakimś sensie, na razie przy webpacku, a to będzie taka ciekawostka, która jest bardzo szybka?

Marek Piechut: Z tym bundlerem jest jedna ciekawa rzecz, bo jak tam przeglądałem różne rzeczy w jego repozytorium, tam jeszcze jest średnio w stanie produkcyjnym, tak naprawdę, bo to powstało jako takie proof of concept, czy w ogóle się da. I okazało się, że się da i on tam dąży do jakieś produkcyjnej wersji. I sam autor mówi, że on nie bardzo chce, żeby to było coś, co zastąpi webpacka. On sam ma taki pomysł, że może z tego będzie moduł, który będzie inkludowany przez inne bundlery, także, to by było dosyć ciekawe podejście, z tym, że on załatwia taki podstawowy use case merdżowania tych Java scriptów. Bo teraz te bundlery, które są współcześnie, czyli webpack czy Parcel, no to one robią sto tysięcy rzeczy, to już nie jest tylko bundling, no więc…

Bartek Witczak: No wiesz, wyszedł też nie dawno room, który ma robić już wszystko i cały świat…

Marek Piechut: Jeszcze zostało coś do robienia? Już mi się wydawało, że webpack robi wszystko… Także wiesz, tu jest taka szansa. I mnie się wydaje, że, to jest jednak takie trochę problematyczne, że społeczność użytkowników nie będzie za bardzo w stanie czegokolwiek tam zmienić. Ci, którym najbardziej zależy, nie będą za bardzo w stanie dopisywać tam kodu, albo będą, ale nikt by takiego kodu nie chciał. No bo pewnie wiesz, jak ktoś usiądzie i przeczyta, że to the royals GO (6:17) albo tam na szybko sobie coś doszpadluje, no to niekoniecznie będzie to miało jakąś jakość.

Bartek Witczak: Pewnie, też, trudno było by tam wejść w taki kod, bo jak troszeczkę patrzyliśmy w sam source code, to jednak styl pisania jest zgoła inny od budowania aplikacji klienckich, przynajmniej taki nowożytny styl.

Marek Piechut: No tak, to jest standardowy problem parcelów kodu, problem kompilatorów, że tam kod wygląda trochę inaczej niż to do czego jesteśmy przyzwyczajeni.

Bartek Witczak: Jasne.

Marek Piechut: Że jakaś tam ogromna liczba if-ów w analizatorze leksykalnym, to jest coś jak najbardziej okej. Czy jakiś switch na pięć ekranów, bo tam nie bardzo da się to jakoś inaczej zrobić, musisz te tokeny po prostu wyparsowywać i jeszcze, jak dochodzi do tego to, że zależy Ci na performersie, no to też nie będziesz jakiś tam polimorficznych parcelów pisać, wynalazków, no bo chcesz to zbudować szybko. No nie oszukujmy się, referencje do funkcji to nie jest najszybsza rzecz na świecie. Trzeba wykonać 75 skoków, żeby jakiś kawałek kodu odpalić, i to nie może zostać zinaninowane (? 7:24) ani nic takiego. Także, tam z reguły będzie taki prosty i prymitywny kod. No ale, to jest ten problem, że tam jest ten GO. Zobaczymy co z tego będzie, bo możliwe, że tam zrodzi się taki kawałek z pluginami, w których ludzie będą tylko dodawać future’y tego nowego JavaScriptu, a core zostanie tylko w tym GO, albo coś w tym stylu. No zobaczymy. Dla mnie to jest ciekawy ruch, właśnie przez to, że w tym momencie build webpacka potrafi trwać bardzo długo i to jest ciekawy ruch, który może coś naprawdę zmienić.

Bartek Witczak: Znaczy, mnie się wydaje, że to by było bardzo ciekawe posunięcie i takie ciekawe rozwiązanie, gdyby dało się zrobić tak, żeby wymienić te elementy webpacka czy jakiegoś innego bundlera, żeby właśnie wykorzystał, na przykład tego esbuilda do bundlowania tylko JS-a, a inne rzeczy pozostawił na przykład w innym w innym miejscu. To nie do końca tak się pewnie da…

Marek Piechut: To nie będzie takie proste, bo jeżeli ty reasolwujesz te wszystkie reasorsy i musisz zbudować z tego jedną paczkę, która będzie miała referencje do rzeczy w Runtime generowanych, to musi jednak trochę współpracować, ale jeżeli sam autor widzi taki kierunek, to możliwe, że właśnie w tą stronę to pójdzie. Ja też mam taką…, trochę przygotowałem sobie historię tych bundlerów, bo to jest dosyć ciekawy kierunek. Nie wiem, czy kojarzysz jaki był pierwszy bundler, taki - przynajmniej mainstreamowo, jaki ja widziałem to był Browsery 5 w 2013 i to był właśnie taki prosty tool comantleinowy , który dostawał listę js-ów, on tam wszystkie rozwiązywał zależności i wypluwał z tego jednego wielkiego bundla. Jak chciałeś go dalej minifikować czy coś tam, no to trzeba było mieć następne toole i to po prostu peipowałeś sobie tymi stremami i to tak działało.

Bartek Witczak: Nie jestem pewny, czy to na pewno było tak, że Browsery 5 był pierwszy, czy nie było jeszcze Grunta. Bo w sumie Grunt był task menagerem, więc to nie do końca był bundler, ale nie wiem, czy jakieś fragmenty jego nie robiły właśnie bundlowania aplikacji.

Marek Piechut: No Grunt był z Bowerem. I Bower był takim…, ale Bower miał swoje repozytoria…

Bartek Witczak: Ale Bower miał swoje repozytoria, tak.

Marek Piechut: I to był problem, że to nie były MPN-owe repozytoria, tylko były swoje i to pewnie go zabiło, bo nikomu nie chciało się już utrzymywać pięciu różnych repozytoriów. Dlatego, wydaje mi się, że to był dobry kierunek, że przeszliśmy na te repozytoria MPN-a. No ale taki pierwszy bundler, z którego ja korzystałem, to był Browsery 5 i, z tego co patrzyłem, to był taki pierwszy mainstreamowy, w ogóle…

Bartek Witczak: Okej

Marek Piechut: W ogóle bundler, jako taki, który z MPN-a korzystał i on był bardzo prosty. W 2015 powstał webpack, z którego korzystamy do tej pory, bo osobiście nie widzę powodów, żeby używać czegoś innego, jak na razie nic nie wnosi nic więcej.

Bartek Witczak: Każdy nowy bundler, który powstaje daje nowego future’a, który 2 dni później jest w webpacku.

Marek Piechut: I webpack, chyba powstał - nie wiem czy ty pamiętasz, ale ja coś kojarzę – on powstał, dlatego że Browsery 5 nie miał splittowania bundli automatycznego, że wiele entrypointów nie mogłeś zrobić. I to był ten główny problem, dla którego zaczął powstawać weebpack, a potem zrobił się z tego taki kombajn, że w webpacku masz wszystko, że weebpack robi obrazki, cuda niewidy, tam splittuje, trechacking, szmery bajery, wiesz fonty embeduje, sprawdza po rozmiarze i tak dalej. No jest takim mega, ultra kombajnem ze swoimi louderami, że tam możesz mieć trochę kodu w TypeScripcie, trochę bez TypeScriptu, trochę we FLOW, trochę w czymś tam, i on tam to wszystko poskleja. No i była część ludzi, która się pogniewała na tego webpacka i w 2017 powstał Parcel, który miał rozwiązać problem, że weebpack wymagał konfiguracji. I tak, mniej więcej, gdzieś tam koło tego roku, webpack zrobił wersję 3.0 - może rok później, która jest bez konfiguracji. W sensie, że zanim Parcel zdążył się dobrze zadomowić, to już webpack miał to samo ogarnięte. I to samo było z tymi bundlami, chociaż webpack, ostatecznie, okazało się, że ma więcej future’ów, czyli jest takim mega kombajnem. Ale to też znowu ten klimat taki sam, że Browsery 5 nie miał tych wielu entrypointów, więc powstał webpack, zanim webpack zdążył się dobrze przyjąć to goście w Browsery 5 już dodali wiele entrypontów. Taki standardowy problem open source, czyli chce mieć swojego… (12:10) i być sławnym.

Bartek Witczak: Dokładnie

Marek Piechut: No ale, tam ten webpack się jednak skończył taki, że tam jednak dużo takich rzeczy jest, których w Browsery 5 nie ma albo nie są takie łatwe. No i druga rzecz, która mi się podoba a propo Parcela, że w ogóle na jego głównej stronie i w celach jest to, że on miał być taki super szybki. No i właśnie przy okazji tego Esbuilda były testy i Parcel wypadł najgorzej.

Bartek Witczak: To jest bardzo ciekawe.

Marek Piechut: Trwał jakiś tam duży projekt w Parcelu 60 sekund, w webpacku 40 coś, a ten Esbuild 100 mili sekund czy coś takiego.

Bartek Witczak: Znaczy, to jest taka rzecz, która na tyle mocno wyróżnia tego Esbuilda, że rzeczywiście jest szansa, że on gdzieś może znaleźć swoje miejsce, no nie?

Marek Piechut: No jest to po coś.

Bartek Witczak: Tak, nie jest tak prosto zmienić.

Marek Piechut: Tak, to nie jest coś, co się da dodać do webpacka, że on nagle będzie 100 razy szybszy, bo to…, ja myślę, że tam chłopaki i tak już nad tym pracują, ale 100 razy uzyskać to będzie bardzo trudno.

Bartek Witczak: Dodatkowo, jakby, zaletą tego, że jest napisany GO jest to, że może pójść na wielu wątkach, przez to jest taka szybkość. Tam, zresztą, też na stronie są pokazane testy, jak on leci na jednym wątku i na wielu i widać, że jeszcze jest to przyśpieszone.

Marek Piechut: Tak, ale wiesz, jak to jest w stylu, że na jednym wątku jest 50 razy a na wielu wątkach jest 100 razy.

Bartek Witczak: Dokładnie

Marek Piechut: Znaczy, mnie się wydaje, że to jest nie do przeskoczenia, ten motyw, że tam nie ma WMA, że to jest natywny kod.

Bartek Witczak: Brzmi spoko. My ostatnio byliśmy, znaczy nie tak ostatnio – jakiś rok, może półtora roku temu – na projekcie, gdzie rzeczywiście już ten czas budowania tego projektu, troszkę już zaczynał doskwierać, przy takim developmencie. Nie wiem, czy pamiętasz, że to już właśnie się zbliżało pod taką minutę ten pierwszy RAN i…

Marek Piechut: Ja Ci powiem, że teraz mam projekt w którym jest użyty jakiś tam starter, taki starter pack, wiesz, w stylu Key and (14:21) i on tam z czterema komponentami się tyle buduje, więc tam po prostu jest jakiś ocean lauderów i tak dalej . Albo, nie wiem, Gadzbe, film w Gadzbe trwa, wiesz, 2 minuty, bo obrazki optymalizuje i cuda na kiju. Jakby ten esbuild tego nie rozwiąże, bo ładowania obrazków nie rozwiąże, no ale wydaje mi się, że to już dochodzi do absurdalnych rzeczy, biorąc pod uwagę, że kompy są takie szybkie, to ja nie wiem, to już wygląda jak kompilacja, wiesz, Windowsa w C++ powoli, że tam na noc trzeba włączać, żeby się zbudowały.

Bartek Witczak: No tak, ale to jest, jakby cała historia tego, jak front-end idzie. Idzie, po prostu, już w taką mega złożoną strukturę i tych elementów, które trzeba ogarnąć jest już tak dużo, że to niesie ze sobą te koszty, że wydawało by się, że kompy są mega szybkie, ale tych rzeczy jest tyle do zrobienia, że…

Marek Piechut: Także, wydaje mi się, że Esbuild jest ciekawy. Będziemy obserwować, bo tam na razie nie da się, jakby tak - wskoczyć od razu. No i zobaczymy co tam z tego urośnie.

Bartek Witczak: Bardzo podoba mi się nastawienie tego twórcy, który nie ma, tak mi się wydaje, takiego dużego ego, które mówi, że zastąpi cały świat bundlerów i ….

Marek Piechut: …będzie tylko mój.

Bartek Witczak: ..będzie tylko jego. No dobra.