Máte Node, máte npm, máte Express. Všechno funguje. Tak proč vůbec číst dál?
Protože existuje nástroj, který dělá totéž, akorát rychleji, a k tomu přidává věci, na které jste v Node potřebovali pět externích balíčků. Jmenuje se Bun a tenhle článek není o tom, proč byste měli přejít. Je o tom, jak na to, pokud se rozhodnete.
Bun napsal Jarred Sumner a první stabilní verze vyšla na podzim 2023. Pod kapotou neběží V8 jako v Node, ale JavaScriptCore, ten samý engine, co pohání Safari. Celý runtime je napsaný v Zigu, což je nízkoúrovňový jazyk, který cílí tam, kde dřív vládlo céčko. To vysvětluje, proč je Bun tak rychlý. Není to magie, je to jiná sada technických rozhodnutí.
Co je podstatné: Bun se od začátku staví jako náhrada Node, ne jako alternativa. To je důležitý rozdíl. Deno, který přišel dřív, si řekl „uděláme to jinak a líp”. Bun si řekl „uděláme to stejně, akorát rychleji”. Proto rozumí vašemu package.json, proto spouští vaše existující skripty, proto funguje s vaším kódem bez přepisování. Aspoň většinou, k výjimkám se dostaneme.
Instalace a první kontakt
Instalace je jednořádková záležitost. Na Linuxu a macOS:
curl -fsSL https://bun.sh/install | bashNa Windows funguje Bun od verze 1.0 nativně, bez WSL.
powershell -c "irm bun.sh/install.ps1|iex"Po instalaci máte k dispozici jediný příkaz, bun, který funguje jako Node, npm i npx dohromady.
Teď to nejzajímavější. Vezměte svůj existující projekt v Nodu a zkuste:
bun install
bun run index.jsTo je celé. Žádná migrace, žádná konfigurace, žádný nový konfigurační soubor. Bun přečte váš package.json, nainstaluje závislosti do node_modules (ano, používá stejnou strukturu) a spustí váš kód. Ten pocit „to je celé?” je záměrný, přesně tohle je strategie Bunu, jak snížit bariéru přechodu na minimum.
Samozřejmě ne vždy to dopadne takhle hladce. Ale překvapivě často ano, a to i u projektů s desítkami závislostí. O tom, kde to zaskřípe, si povíme později.
Bun jako správce balíčků
Pokud znáte npm, znáte i Bun. Příkazy jsou téměř totožné: bun add místo npm install, bun remove místo npm uninstall. Přidání vývojové závislosti je bun add -d, globální instalace bun add -g. Nic překvapivého, nic, co by vyžadovalo přeučení.
Rozdíl je v rychlosti, a je znatelný. Kde npm přemýšlí dlouhé sekundy, s tím je Bun za zlomek času. Není to o pár procent, je to řádový rozdíl. Důvod je technický: Bun řeší závislosti paralelně, používá rozsáhlou globální mezipaměť a k síti přistupuje efektivněji.
Zásadní věc, na kterou narazíte hned, je lockfile. Npm generuje package-lock.json, textový soubor, který si přečtete, porovnáte v gitu, projdete očima. Bun generuje bun.lockb, binární soubor. Nedá se číst, nedá se rozumně porovnávat při revizi kódu. Je to vědomé rozhodnutí ve prospěch výkonu. Pokud potřebujete textový výstup pro ladění, existuje bun bun.lockb, který vypíše obsah v čitelné podobě, ale pro denní práci s gitem je to komplikace, se kterou musíte počítat.
V praxi to znamená: pokud pracujete v týmu a všichni používají Bun, binární lockfile vám nevadí, prostě ho uložíte do gitu a hotovo. Pokud ale někdo v týmu zůstává na npm, máte problém, protože dva různé lockfily vedle sebe jsou trabl. Tady je potřeba se rozhodnout: buď přejde celý tým, nebo nikdo.
Ještě jedna věc, která potěší: bun install automaticky používá globální mezipaměť. Pokud jste nějaký balíček už někdy instalovali v jakémkoliv projektu, Bun ho má uložený a příště ho vytáhne odtud místo stahování. Npm to umí taky, ale u Bunu je to výchozí chování, nemusíte nic nastavovat.
Bun jako spouštěč
Tady se to trochu zamotá, protože příkaz bun dělá víc věcí najednou a je dobré vědět, co přesně se děje, když ho zavoláte.
bun run script.js spustí JavaScriptový soubor. To je přímá náhrada node script.js. Ale bun run umí víc. Pokud mu dáte název, který odpovídá klíči v sekci scripts vašeho package.json, spustí ten skript. Takže bun run dev je totéž co npm run dev, jen rychlejší, protože Bun nepotřebuje spouštět nový proces shellu. A protože jsme líní, tak bun run dev jde zkrátit na bun dev. Pokud neexistuje vestavěný příkaz stejného jména, Bun to pochopí správně.
Pak je tu bunx, obdoba npx. Stáhne a spustí balíček, aniž byste ho museli instalovat. bunx cowsay "ahoj" funguje přesně tak, jak čekáte. Oproti npx je bunx výrazně svižnější, protože využívá stejnou globální mezipaměť jako bun install, tedy pokud balíček někde v systému už je, nezdržuje se stahováním.
A teď to nejpříjemnější pro každého, kdo někdy konfiguroval TypeScript v Nodu. Bun spouští .ts soubory přímo. Žádný ts-node, žádný tsx, žádný tsconfig.json na to, aby vám to vůbec nastartovalo. Napíšete bun run server.ts a ono to běží. Bun transpiluje TypeScript za běhu, interně, bez mezikroku. Pro vývoj je to velké zjednodušení. Pro produkci se sice stále vyplatí kód předem zkompilovat, ale pro lokální práci odpadá celá vrstva konfigurace, kterou jste v Node museli řešit.
Totéž platí pro soubory .env. Bun je načítá automaticky, bez balíčku dotenv, bez volání require('dotenv').config() na začátku skriptu. Proměnné prostředí z .env souboru jsou prostě k dispozici v process.env i v Bun.env. Drobnost, ale přesně ten druh drobnosti, který v součtu ušetří docela dost času a mentální energie.
Ano, právě minulý týden jsem strávil půl hodiny kontrolou toho, jestli mi nevyexpirovaly API klíče, než jsem přišel na to, že se “jen” nenačetl .env, protože chyběl dotenv a systém nezařval.
Zatím jsme si ukázali, jak Bun nahrazuje npm i Node a kde šetří konfiguraci. Ale to podstatné teprve přijde: co všechno má Bun vestavěné, za co byste v Node platili externími závislostmi? Pojede váš Express bez úprav, a pokud ano, vyplatí se u něj zůstat? Jaké frameworky pro Bun existují a dají se použít i na Node? A hlavně, kde jsou ty záludnosti, o kterých se v nadšených recenzích nemluví?
