フロントエンド開発環境に Bun を使っている
『Software Design 2024年6月号』に Bun の特集記事「［実証］Bun 次世代JavaScriptランタイムの実体に迫る」があり, それにインスパイアされて Bun はいいぞ記事を書きます.
個人でフロントエンド開発をするときには主に Bun を中心に利用しています. そこで Bun をフロントエンド開発環境として利用する利点や欠点を紹介します. なお開発環境としての利用のみで, 本番環境での配信などでは利用していません.
『Software Design 2024年6月号』の特集記事の中で以下のように語られている通り, Bun の一番の特徴は Node.js が持つ問題点を解決しつつ, Deno にはない Node.js との互換性を持つことと言ってよいでしょう.
DenoではNode.jsが持っていた問題点を解決する次の要素が導入されました。
- pagckage.json、Node_modules、CommonJSの廃止
- ビルトインのテストランナー＆バンドラー
- TypeScriptの標準サポート
しかし、Node.jsとの互換性がなかったため、今まで作成したNode.jsプロジェクトDenoで動かすことができませんでした。移行難易度が高いということもあり、「Denoを使えば解決！」とはいきませんでした。
そこで、Node.jsと互換性を持ち、なおかつNode.jsの問題を解決するようなJavaScriptランタイムの登場が望まれていました。まさにそのランタイムが「Bun」というわけです。[1]
Bun 自身が喧伝している通り, もちろん速さという利点もありますが, この速さの利点を享受できるのはひとえに Node.js との互換性が担保されているためだと思います. この互換性により Storybook や Playwright などフロントエンド開発に必要なツールをそのまま導入することができます. これにより Node.js との単純比較で Bun の速さを実感することができます. Bun は Node.js に比べて不安定な部分もありますが, いざとなったら Node.js に戻すという決定もできます.
Bun の速さについては『Software Design 2024年6月号』で詳しい調査記事が載っているため主観のみの話をしますが, パッケージのインストールやテスト, トランスパイルなど多くの面で実感することができます.
Bun を使っていて最も出くわす問題はライブラリが Node.js のエコシステムに依存していることによるものです. 例えば Storybook ではパッケージの管理をNPMに依存しており, bun x storybook init を実行するとNPMからパッケージのダウンロードが実行されるため, 結局 Node.js とNPMが必要になってしまいます.
これ以外にもデファクトスタンダードとなっている ESLint や Jest を使用することが前提となっていることがほとんどで, Bun を使っても複雑さの解決にはならないことも多いです.
また Node.js との互換性の問題もあります. Bun ではまだまだ安定性に問題があり, Node.js だと動くけど Bun だと動かないということが多々あります. とはいえ Node.js に戻すといった回避策を取ることもできるため, あまり困るような事態には遭遇していません. また Bun のリリースノート[2]を見ればわかる通り凄まじい勢いでバグ修正がされているため, いつの間にか使えるようになっていたということもあります.
上記の通り使っていて不満を感じることはあるものの, それを打ち消すだけの利点を日々実感しています. Bun には安定性の不安が確かにありますが, SPAやSSGであれば本番環境への影響もなく, その利点だけを享受することも可能です. やはり一番の魅力は Node.js との互換性で, フロントエンド開発環境であれば気軽に「 Bun を使ってみる」という決定ができるはずです.
-
Software Design 2024年6月号, 技術評論社 ↩︎
Discussion