JavaScriptの誕生と死
JavaScriptは、非常に限られた権限でブラウザ上で動作します。それにもかかわらず、サーバー、ビルドツール、さらにはデータベースまでも動かしています。これは計画されたことではありません。1995年の決定に基づいた、一連のパッチの積み重ねなのです。
2014年、Gary Bernhardtは「The Birth and Death of JavaScript」という講演を行いました。多くの人はこれを「外れた予言」と見ています。しかし、私はこれをアーキテクチャ上の摩擦を診断するためのツールだと考えています。
Bernhardtは皮肉な道のりを説明しました。JavaScriptは玩具のような言語として始まりました。それが生き残ったのは、ブラウザにおける唯一の言語だったからです。この独占状態により、たとえ技術的に最善の選択ではなかったとしても、地球上で最も実行される言語となりました。
中心にある葛藤は単純です。ブラウザはコードを「安全に」、かつ「高速に」実行する必要があります。これら2つの目標はしばしば衝突します。
2014年当時、WebAssemblyがJavaScriptに取って代わるという予測がありました。しかし、そうはなりませんでした。WebAssemblyは安定しており、FigmaやGoogle Earthのような用途には有用です。しかし、アプリケーション言語としてJavaScriptに取って代わることはありませんでした。
その代わりに、JavaScriptは変異しました。TypeScript、バンドラー、そしてDenoやBunのような新しいランタイムはすべて、Bernhardtが指摘した摩擦を解消するための試みです。
この講演を、JavaScriptの学習を避けるための口実にしないでください。また、真のパフォーマンス問題が発生する前にWebAssemblyへ移行することを正当化するために使わないでください。
自身のスタックについて、以下の問いを投げかけてみてください：
• このツールは、この問題に対する最善の解決策だから使っているのか？ • このコンテキストで動作する唯一の手段だから使っているのか？ • ツールの複雑さは、真の問題を解決しているのか、それとも単に問題を別の場所に移動させているだけなのか？ • もし今日、ゼロから作り直すとしたら、これを選ぶだろうか？
サーバーでTypeScriptを使用すれば、型安全性は得られますが、コンパイルのオーバーヘッドが増えます。Next.jsを使用すれば、機能は増えますが、キャッシュの複雑さが増します。これらは現実的なトレードオフです。
最も多い間違いは、実際には使い方が悪いだけなのに、言語のせいにしてしまうことです。イベントループをブロックするような重い同期コードを書いているなら、問題はJavaScriptではなく、あなた自身にあります。
魔法のような代替策を探すのはやめましょう。実際のボトルネックを測定し始めてください。