22. 結論

JavaScript が作成されたときの期待度は低かった。元々はブラウザの中で動作する Java の弟分として作られた言語であり、想定されたユーザーはウェブページ開発の初心者とアルバイトのプログラマだった。しかし JavaScript は対話的なウェブページ用の言語としてすぐに Java を追い越した。JavaScript の最初の 20 年には JavaScript を拡張、改善、再設計、置換しようとして失敗した試みが数多く散乱している。しかしそれでも、20 年が経過するころには JavaScript は世界で最も使われる言語となった ── その用途はウェブページにとどまらない。Node.js をはじめとしたホストを使って作られるサーバーアプリケーションに加えて、JavaScript はデスクトップアプリケーション、モバイルデバイスアプリケーション、フィットネストラッカー、ロボット、そして数えきれない数の組み込みシステムを構築するのに使われている。ジェイムズ・ウェッブ宇宙望遠鏡さえオンボードの制御ソフトウェアの一部として Nombas による ES1 レベルの組み込み JavaScript を使っている [Dashevsky and Balzano 2008]。

JavaScript の台頭は避けられないことだったのだろうか？ ウェブが課す相互運用性の要件とブラウザゲーム理論は単一の支配的なウェブページ用プログラミング言語を生み出す上で好都合だったかもしれない。しかし、その言語が JavaScript でなくてはならなかった特別な理由は存在しない。他の言語でも同じ役割を果たすことはできただろう。考えてみれば、JavaScript の歴史の中には未来が変わっていた可能性のあるポイントがいくつも存在する:

• もし、Mark Andreessen がブラウザ向けスクリプト言語を擁護していなかったら？
• もし、Sun の Bill Joy が Java を補完する言語として Mocha に取り組むことを最初に支持していなかったら？
• もし、Mocha を開発するタスクが Brendan Eich 以外の人物に割り当てられていたら？
• もし、Eich がもっと経験を積んだ言語設計者あるいは言語実装者で、10 日間でデモを作るなど不可能だと結論付けていたら？
• もし、Eich のプログラマとしての腕が足りなかったり、言語設計が野心的すぎたりしたために、彼が 10 日間で Mocha のデモを作るのに失敗していたら？
• もし、JavaScript のオリジナルの設計がファーストクラスの関数を含んでいなかったら？
• もし、Sun あるいは Netscape が隔離された環境として Java をホストするのではなく、Java を HTML と統合させるのに労力をもっと注いでいたら？
• もし、Microsoft が JScript を実装せず、もっと強力に宣伝されていた Visual Basic を代わりに使っていたら？
• もし、Microsoft が 90% 以上のブラウザマーケットシェアを獲得した後もブラウザ言語技術への投資を続けていたら？
• もし、Macromedia/Adobe が ES4₂ の再設計に参加せず、ActionScript 2 あるいは ActionScript 3 を公式のブラウザ規格にするよう推進していたら？
• もし、ES4₂ への反対意見が TC39 内で生まれなかったら？

もし、もし、もし……しかし、そういった「もし」はどれも起こらなかった。実際には、各世代のブラウザ実装者、エンジン開発者、フレームワーク設計者、規格貢献者、ツール構築者、そしてウェブアプリケーションプログラマが、手厳しい批判に (ときには嘲笑にさえ) 直面しながらも、ウェブをほぼ壊すことなく JavaScript を上手く利用し改善する実用的な方策を見つけたのである。

Brendan Eich は「JSLOL」と題された 2011 年のカンファレンストーク [Eich 2011e] で、JavaScript を次のように特徴付けた:

• 最初、JS は「リッチインターネットアプリケーション」を構築する上で役に立たないと彼らは言った
• それから、JS は高速になれないと彼らは言った
• それから、JS は修復できないと彼らは言った
• それから、JS はマルチコアや GPU ができないと彼らは言った
• どれも間違いだった！

私からのアドバイス: どんなときでも JS に賭けよ