JavaScriptのミッドライフクライシス

JavaScriptのミッドライフクライシス

少し前に、LinkedInで半ば観察、半ば冗談のような投稿をしました。

［画像: All the JavaScript build tools are competing to see who uses the least amount of JavaScript.］

JavaScriptのツールチェーンの大規模な書き換えが勃発しました。かつて私たちのスタックにおける言語の地位を確立するのに役立った古いツールは、疑わしいとまではいかなくても、クールではなくなりました。それらの遅いパフォーマンスが、プロダクションへの何百万行ものコードを遅くした原因だと非難されました。今どきのクールなツールを追跡するのはますます困難になっています。それらの名前はキャッチーではないかもしれませんが、その約束は魅力的です――スピード、それも大量のスピードです。

JavaScript開発者にとっては奇妙な時代です。この言語はかつてないほどユビキタス（遍在）していますが、自らの庭で足場を失いつつあるように見えます。ツールはより高速になり、セットアップは容易になり、抽象化はより厚くなりました。私たちは書く、設定する、待つ時間が減りました。バンドルする、出荷する、ホットフィックスする時間が増えました。私たちのコードと最終製品の間で何が起こるのかは、無視しやすくなりました。

ベンチマークはすべて緑色に輝いています。折れ線グラフは右肩上がり、下がり、あるいは横ばいになっています――いずれにしても、深夜3時の呼び出しが少なくなる方向を意味します。では、なぜ私がパーティーを台無しにするためにここにいるのでしょうか？

死なない言語

（悪名高く）10日間で書かれた言語にしては、JavaScriptは不可能を達成しました。ブラウザという出生地から逃れ、周囲のあらゆるものを飲み込み始めました。その反応は予測可能でした。「正気の人なら誰がサーバーやツールをJavaScriptで書くというのか？」と。結果として、多くの多くの人々がそうしました。JavaScriptは携帯電話、ゲーム機、マイクロコントローラー、そしてあなたの冷蔵庫にまで進出しました。ビットを理解できるものなら、JavaScriptを実行できます。

その人気にもかかわらず、JavaScriptは決して楽な道のりを歩んできませんでした。その誕生から間もなく、それを修正する、あるいは完全に置き換える試みがすでに始まっていました。MicrosoftはInternet ExplorerにVBScriptとJScript、独自のJavaScriptフレーバーを搭載しました――J-PopやJRPGと混同しないでください。90年代には、Jで始まるものは何でもクールに聞こえました。Macromedia、そして後にAdobeは、ActionScriptで動くFlashイントロやゲームでインターネットを賑わせました。GoogleはChromeの未来のためにDartに賭けましたが、後にFlutterに追いやられました。

CoffeeScriptのようなプロジェクトは、JavaScriptのカップにシンタキシスシュガー（構文糖衣）を加えました。JavaScriptを置き換えようとしなかったときは、外部からそれをパッチすることに忙しくしていました。jQueryは、ブラウザ同士がほとんど口を利かない状態だったWebプラットフォームを統一しました。Lodashは、言語の配列やオブジェクトの明白なギャップを埋めました。Moment.jsは、日付の問題を他人の問題にしました。

JavaScriptも、皆がその終焉を企てている間にじっとしていたわけではありません。そのシングルスレッドの中で、それはかなり忙しくしていました。ブラウザベンダー、標準化団体、そしてコミュニティは、この言語を前進させ続けました。ECMAScriptのリリースは、長らく待ち望まれていた言語機能をもたらしました。TC39は提案を次々と出し続け、ブラウザはJavaScriptが何をすべきかについて徐々に合意できるようになりました。時が経つにつれて、その標準ライブラリは恥ずかしいほどまばらではなくなりました。

そしてTypeScriptが登場し、JavaScriptの頭はついに銀の皿に乗せられました。少なくともそう見えました。TypeScriptは、他のプロジェクトが失敗した場所で成功しました。それは、一つの不都合な真実を受け入れることによってです：JavaScriptはどこにも行かないということです。

それを改善することも、隠すことも、それにコンパイルすることも、それについて文句を言うこともできます。ただ、それを取り除くことはできませんでした。

私たちが手放しているスーパーパワー

すべてを支配する一つの言語は、祝福でもあり呪いでもあります。私たちは何十年もその呪いについて話してきました。いつの間にか、私たちはその祝福について忘れてしまいました。

JavaScriptが広がり続けるにつれて、それは自らのドッグフードを食べ始めました。Node.jsは、多くのツールが登場し、エコシステムを征服することを可能にしました。リンター、バンドラー、フォーマッター、テストランナーは、それらがリンティング、バンドル、フォーマット、テストするコードと同じ言語を話していました。

もし、いや、むしろ「いつ」そのツールチェーンで何かが壊れた場合、平均的なJavaScript開発者はそのコードを確認できるでしょう。おそらくバグを理解できるでしょう。もし8時間睡眠をとっていれば、おそらくそれを修正できるでしょう。もし戦う気分であれば、プルリクエストを提出できるかもしれません。少なくとも、バグの責任をメンテナーに押し付けるのに十分な知識はあったでしょう。

そしてその親しみやすさは驚くほどよく伝わりました。同じ言語が、開発者をブラウザからサーバーへ、そして最終的にはその間のほぼすべての場所へと追随しました。JavaScriptはフルスタックエンジニア、あるいはフルエコシステムエンジニアの台頭を加速させました。誰かが本当にスタックの両端をマスターできるかどうかは、別の日の議論です。しかし、JavaScriptはその移行を著しく容易にしました。エンジニアは、コールスタック、プロトタイプベースの継承、そして typeof null === "object" という不幸な事実に関する知識を、ほぼすべてのプロジェクトに持ち込むことができました。

人々はこの万能なエコシステムを中心に、キャリア全体やビジネスを築き上げました。そのほとんどがオープンソースで無料であった、そしてあり続けているという事実は確かに助けになっています。

JavaScriptはブラウザ戦争に勝ち、他のいくつかの重要な戦いでも勝利しました。そして次に、Rustとその仲間たちがトロフィーと記念写真のために現れました。

ミリ秒の追求

Rust、Go、Zigは、JavaScriptツールチェーンのますます大きな部分を占めつつあります。そして、その明白な理由があります。

それらは高速です。非常に高速です。

私たちはRustでJavaScriptをコンパイルし、主にC++で書かれたエンジン内で実行されるJavaScriptを生成しています。

誰も進捗バーに感情移入するほどビルドプロセスを長く見つめたいとは思いません。しかし、すでに高速なツールの代替品が10倍高速だと宣伝している場合、それが私たちに返してくれた貴重なミリ秒を何に使うべきか疑問に思い始めます。

コーヒーをもう一口飲む？

より重要なのは、そのスピードのために何を犠牲にしたのかということです。

バンドラーをRustで書き直すと、それを高速にしただけではありません。それを保守できるJavaScript開発者のプールも縮小しました。新しいツールはまだアヒルのように見え、アヒルのように鳴きますが、それは全く異なる獣です。その内部は、より少ない人々が鍵を持っているブラックボックスの背後に隠れます。ソースコードはまだ公開されているかもしれませんが、貢献への扉は閉ざされつつあります。

おそらくそれは完全に合理的なトレードオフでしょう。しかし、それはトレードオフです。そして、私たちはベンチマークのその側面には特に興味がないようです。

光るものすべてが金ではない

時にはそれは錆びています。

ソフトウェアエンジニアリングは、常に特に深刻な「キラキラした物体症候群」に悩まされてきました。言語にはその瞬間があります。フレームワークが流行になります。いくつかの成功したプロジェクトがパターンを確立し、企業がそれに投資し、カンファレンストークが続き、ラップトップステッカーが配られ、突然、技術的な決定が主要なセールスポイントになります。

「Rustで書かれている」というのが、実装の詳細というよりは機能のように聞こえ始めます。

成功は模倣を生みます。あるツールが書き直され、劇的に高速になります。別のツールが続き、さらに別のツールが続きます。同調圧力が高まります。すぐに、JavaScriptで書かれていることが、JavaScriptツールのための明白な選択肢というよりは、負けの賭けのように見え始めます。

私たちは、時間をかけるのが好きな蒸気機関車のために、ますます高速な線路を敷設しています。

これらすべてが、コンパイルされた言語がその仕事に間違ったツールであることを意味するわけではありません。多くの場合、それらはまさに正しいツールです。しかし、「この仕事に最適なツール」と「競合他社がやっていることに少しでも似ているあらゆる仕事に最適なツール」の間には違いがあります。

輝かしい新しいツールがベンチマークでもトップになったら、それに抵抗するのはかなり難しくなります。スピードが技術的な議論を提供します。トレンドが残りを処理します。

目的地不明

より高速なJavaScriptの追求は、私たちを非常に奇妙な場所に連れて行きました。

私たちはRustでJavaScriptをコンパイルし、主にC++で書かれたエンジン内で実行されるJavaScriptを生成しています。

おそらくそれが成熟したエコシステムの自然な進化であり、JavaScriptは関連性を保つためにスタック全体を飲み込む必要はないのかもしれません。言語は共存し、それでも繁栄できます。ウェブは、さらに多くの言語が加わる前に、少なくとも3つの言語の上に構築されました。

個別に考えると、すべてのステップは理にかなっています。しかし、それらをまとめると、より興味深い何かに繋がります。私たちはJavaScript自体が目的地である一方で、JavaScriptの周りのすべてを最適化するためにかなりのエンジニアリングを投入しています。私たちは、時間をかけるのが好きな蒸気機関車のために、ますます高速な線路を敷設しています。

スピードに関する問題は、列車自体が追いつくように設計されていない場合、必ずしもスムーズな旅を保証するわけではないということです。遅かれ早かれ、より高速な線路の影響はますます小さくなります。そして、私よりもはるかに賢い誰かが、難しい質問をしなければならないでしょう：ウェブをゼロから再構築することが、より健全な選択肢に見えるようになる前に、どこまで行けるのか？