Bunのハイプ。Yarnから何も学ばなかった

またやってしまいましたね、同じ過ちを。プログラマーの数は5年ごとに倍増するという話を何度も聞き、つまりどの時点でも業界の50%が5年未満の経験しかないわけです。だからこんなBunに騙され続けるんでしょうね。でもこの映画は前にも見たことがあって、結末も知っています。

第1部 - Yarnの物語

私はYarnとBunには多くの類似点があると思います。どちらも既存のオープンソースシステムを対象にし、それに実際に貢献する代わりに、独自の競合する技術を作りました。どちらもかなり高速だと自己宣伝していました。どちらもエコシステムを分裂させようとしています。どちらも後方互換性のサポートが良くなかったです。そしてどちらも公式にv1.0でプロダクション準備完了を宣言しました！ ...Windowsをサポートしていない状態で（つまり、実際には全然プロダクション準備完了ではない）。

それでYarnはどうなったかと言うと、npmにはなかった12ものクールな新機能を出しました。そしてnpmより何倍も高速でした。でもそれから...わずか1年後にはnpmがYarnよりも早くなりました。さらに1年後、Yarnはnpmよりも早くなることは決して不可能であると説明するブログ記事を作成しました。というのも、npm CLIがパッケージを保管してダウンロードするnpmサーバーを管理する同じ人たちによって作られたからです。そしてそれは今日でもそうです。2023年でも、npmは依然としてYarnよりも速いです。元々の大きなセールスポイント...は5年も前から関係なくなっています。

でも、Yarnが提供していたその他の機能はどうでしょうか？年が経つにつれて、それらはどんどんnpmに組み込まれ、現在ではYarnが独自に提供していた全ての機能がnpmに組み込まれています。確かに機能の実装は少し異なり、Yarn、Lerna、Turbo、npmがモノレポ管理を扱う微細なニュアンスを本当に気にする人々にとっては、一つを他のものより好むかもしれません。しかし、大多数のユースケースにおいて、npmがこれらの機能を実装する方法はほとんどのユーザーにとって完全に問題ありません。

でも、Bunは違うんですよね？違いますよね？だって、ZIG! で書かれてるんですから。そして ZIG! はとても速い...じゃないですか？ええと、実際そうではありません。何も魔法は使っていませんし、実質的に何らかのパフォーマンスを達成することができれば、それはC++（Node.jsが書かれている言語）でも達成可能です。ですから、かつての遅いnpmの話と同じです。パフォーマンスを優先させると、npmは競合よりも速く（さらに速く）動けるようになりました。Nodeでも同じことが起こると見ています。適切な注目を集めれば、わずかな違いを無視できるくらい、およそ同等のスピードが可能になるでしょう。まぁ...いいんですけど。ちなみに、Bunが自慢するベンチマークのいくつかは、えり好みしたものだったり誤解を招くものですから、実際、Bunも自らのマーケティングハイプに達していません。でも、伝わると思います。

Yarnのたとえ話に戻ります。Yarnが出た時、それはWindowsをサポートしていると_言っていました_。けれどもYarnを開発しているFacebookの開発者たちは、Windowsを主要なOSとして使用していませんでした。ですから、実際にはYarnはそのプラットフォームで動かないということがすぐにわかりました。

_ちょっとした余談です：_こんにちは、Primagen（他の人は読み飛ばしてください）。Windowsについて皮肉なコメントをしたのは知っています。しかし、もしかすると、我々の社会での多様性を_本当に_尊重して、異なる生き方を受け入れるべきかもしれません。その理由は、完全に理解しています。Windowsユーザーは非常に非常に少数派だと、たったの90％のコンピュータユーザーしかいないのですから。でも、そのほとんど気づかないような少数を尊重すべきかもしれないですよ。:)
物語に戻ります。

結局、2週間ほど経って、彼らは「修正」し、YarnがWindowsでインストールして動かせるようになりました...なんとなくですが。私は個人的には、corepackを導入してからYarnがWindowsで確実に動くようになるまで、Yarnを信頼してWindowsで使うことはありませんでした。npm経由でcorepackをインストールし、その上でYarn(またはpnpm)をインストールするようになってからやっと、バグもクラッシュもない、信頼できるWindows対応が実現しました。しかし、その時点でFacebookはすでにYarnを捨てており、その後はゆっくりとみんなもそうしました。Windowsで動作するようになってからずっと後退していきました。

私は今日に至るまで、一度たりともYarnのモノレポをWindowsで動かすことができたことはありません。それが不可能だと確信しています。それが動くと言う人はあなたに嘘をついています。もしかすると、Windowsアップデートすらインストールされていない何もないWindows VMで、_もしかしたら_誰かがWindowsでYarnモノレポを動かすことができ、数秒間栄光を手に入れたかもしれません。そして、山の中でサスクワッチを見たかもしれません。何でも起こり得ます。しかし、本物の開発者のラップトップでは、PATHにランダムなものがあり、Nodeやnvm-windows、voltaやその他ランダムなものがインストールされているといった状態では、いいえ、動きません。

では、Yarnが来てnpmを改善させた後、消えていったというのは何が問題なのでしょうか？それだけであれば、Yarnは素晴らしかったでしょうが、それだけではなかったんです。npmはユーザーが必要とする機能を開発してリリースに集中していました。しかし、Yarnは_Facebook_が必要とする機能に焦点をあてていました。それらの機能は、npmを使用する99％の人々にとって重要ではありませんでした。ただし、人々がYarnを使用し始めると、npmはエコシステムが分裂するのを避けるため、どの機能を開発してリリースするかを再優先しなければなりませんでした。もっと多くのユーザーにとって関係ある洗練された高価値の機能を提供する代わりに、Yarnが提供していた機能に匹敵する機能を素早く追加する必要がありました。しかし、Yarnは自分たちをとても上手くマーケティングし、人々はハイプを信じ込みました。私もYarnが出た当初はとてもハイプされていましたが、Windowsで実際に動かないことを知ってからは、その興奮を抑え、実際的で歴史的な観点から見るようになりました。

そして、それからYarnは部族的なものになりました。愚かな人間たち。何でも部族的にならなければならないんです。そして数年間にわたって、_ただ_プロジェクトのインストール方法を教えてくれるYarnの指示だけのREADMEが何千も作成されました。新しい開発者を混乱させます。Yarnというものを明確に説明してもらうために私のところに来る初心者開発者の数を数えることはできません。彼らが見つけたプロジェクトが_Yarnでしか_動かないと思っていました。みんなの時間と精神を無駄にしています。

私はいつも、Facebookで誰かが、オープンソースプロジェクトに機能を追加するために費やした時間を担当者に説明するのが難しいと感じていたと思っていました。それをマーケティングに使えるとすれば、その機能に取り組む許可を得るのはもっと簡単だったんじゃないかと。いつもここで発明されなかった症候群が匂ってきます。

Facebookがnpmに欲しい機能を提供していれば、それらの機能はnpmが既に取り組んでいた機能と一緒にリリースされていたでしょう。しかし、代わりに他の機能のリリースが何年も遅れ、努力が二重になりました。そして、それら全てのために何になりましたか？この時点ではYarnは基本的に死んでいて、ごく限られたニッチなエッジケースを除いてはありません。過去1年から2年間、私はyarn addをREADMEで見たことがない。過去の時代の印象です。

第2部 - 実際にBunはもっと悪い

Yarnが速度と新機能を12個提供したのに対し、Bunは速度と3個の新機能を提供します。それらを簡単にレビューしましょう。

1. マクロ - ビルドプロセス中に使用されます。一部には間違いだと呼ばれています。私の最大の懸念は、ビルドプロセスがBunで固定されることです。同等のマクロシステムを持っていない限り、他のものに切り替えることができませんし、ビルドプロセスを書き換える必要があります。将来的な技術的負債に自発的に同意している状態です。
2. bun.x API - これらはNode.jsのAPIと文字通り同じことをする新しいAPIですが、「より速い」というだけ。これはマクロよりも悪化していますが、今度はあなたのコードにBunというウイルスが感染しました。私があなたのパッケージをnpm installしてNodeで実行すると、「ReferenceError: Bunが定義されていない」というエラーが出るでしょう。あなたのライブラリの全ユーザーにBunを採用させることを強制しています。これはエコシステムを分裂させるもう一つの強制ですが、Yarnが行っていたのと同様ですが、はるかに悪化しています。
   • もしかしたら、bunが存在していれば、高速なAPIを使用するラッパーライブラリをimportして、存在していない場合はNodeにフォールバックするかもしれません。もしBunが多少なりとも人気になれば、これは非常に一般的になると想像されます。しかし、それはプロジェクトで管理する必要のあるもう一つの依存関係であり、「オールインワン」システムが便利なツーリングの依存関係を不要にしたいという点を否定することになります。
3. メタ言語サポート - Node.jsにVue-Template-Compilerが組み込まれているべきでしょうか？それを尋ねるのが全く無意味に感じます。Markdown、またはSass、またはCoffeeScriptについてはどうでしょうか？そうですね、それは単なるプラットフォームにメタ言語を組み込むのは非常に短視眼的に感じます。
   • メタ言語はオリジナルの言語のギャップを埋めるために存在していますが、それらは本性上、一時的で柔軟です。それらはあなたの車にオリジナルの言語での道路のでこぼこの上を走るために非常に良いサスペンションを追加するようなものです。オリジナルの言語がでこぼこを埋めるまでの間。CoffeeScriptをもう使わない理由は、それが提供したほとんどの機能がES6で言語に追加されたからです。CSS
     
     こちらの記事はdev.toの良い記事を日本人向けに翻訳しています。
     https://dev.to/thejaredwilcurt/bun-hype-how-we-learned-nothing-from-yarn-2n3j