ブラウザ戦争の始まり
皆さん、こんにちは。 雨宿りとWEBの小噺へようこそ。
パーソナリティーのkeethことくわはらです。
この番組では、目まぐるしく変化するWEB業界の中、
ちょっと一息つける裏話や小噺などをお届けします。
前回、JavaScriptの誕生と設計思想についても触れていったんですけど、
この流れで、ECMAScriptというものの誕生についても気になってしまったんですね。
これは自然の説理なんで仕方ないんですけど、
これについてまとめてみましたので、この話をしようと思います。
何番千字の記事かちょっとわからんですけど、
アウトプットとしては、絵としてそういうものですし、
書きたいから書く、喋りたいから喋るっていうのがアウトプットです。
雑音が増えるっていうことを懸念される方もいて、
それによって検索性が悪くなるかもしれませんけども、
昨今は各種生成エアイクンがとても優秀ですので、
まあ気にしなくても良くなったんじゃないかなというふうに思っています。
まあとても良い時代になりましたね。
はい、ということで今回はブラウザ戦争という激動の時代を経て生まれた
ECMAScriptのストーリーというのを見ていこうかなと思います。
JavaScriptの開発と標準化
ではまず最初にブラウザ戦争、先ほど触れましたね。
こちらから入っていきたいと思います。
最初はNetscape Navigatorというものの登場からなんですけど、
1994年、Netscape Communicationsという会社が
Netscape Navigatorというものをリリースしました。
こちら当時のWebというものは静的なHTMLのみで、
インタラクティブの要素というのはほとんど皆無だったんですね。
マーク・アンドレッセン、Netscapeの共同創業者の方ですけど、
この方がWebというのはもっと動的にしていかなきゃいけないなというふうに思っていて、
結構それが強い思いだったらしいですね。
そこから1995年、Netscapeというのはサンマイクロシステムズ、
現オラクル社と提携しまして、
Javaをブラウザ上で動かすJava Appletというものが登場しました。
ですけど、Javaというのは本格的なプログラマー向け、
エンジニア向けの言語でして、
WebデザイナーとかHTMLを書く人には結構敷居が高かったんですね。
その同年の5月にNetscapeのブレンダー・アイクという方に、
簡単なスクリプト言語を作れというふうな指令が下りまして、
ブレンダー・アイクはわずか10日間でJavaScriptの最初のプロトタイプというのを作成しました。
当初の名前というのはMOCAという名前からスタートして、
後にLiveScriptというふうな名前に変更になりました。
前回もしゃべりました、ブレンダー・アイクの話がここでいきなり登場するわけですね。
彼はNetscape社にもともと所属していたというところです。
で、なんでJavaScriptという名前になったかというと、
これは前回もしゃべった通りで、
Javaの人気にあやかるためのマーケティング戦略というところでした。
The Microsystemsとも先ほど言った通り、提携関係もあったので、
Javaという名前の使用許可というのがありました。
で、それを使ってJavaScriptという名前になった。
でも実際はですね、Javaとは全然異なる言語になりました。
で、ブレンダー・アイク氏もですね、
後にこのことを最悪のネーミングというふうに公開をされています。
で、設計思想については前回触れた通りで、
スキームとかセルフという言語からインスパイを受けています。
いわゆる関数型プログラミングの要素と、
プロトタイプベースのオブジェクト思考というところでした。
あと一部、Javaの構文の一部というのを使っています。
目指したところは素人でも書けるけど、
プロでも満足ができるというような言語を目指しておりました。
時は経て、同年の8月、1995年ですね。
の8月にWindows 95と共に
Internet Explorer 1.0というものがリリースになりました。
翌年1996年、IE 3.0でJScriptが実装されました。
こちらはJavaScriptを独自にリバースエンジニアリングして実装したものらしくですね。
両者には微妙な仕様の違いというのが多数存在してしまいました。
で、開発者は悩まされます。
IE向けにはこの書き方をしなければいけない。
ネットスケープナビゲーターにはこういう実装しなきゃいけない。
みたいなことを開発者やってたんですね。
具体的に言うと、ナビゲーターオブジェクトの中のアップネームですね。
navigator.appnameイコールネットスケープであったらネットスケープの処理をすると。
navigator.appname.indexofにマイクロソフトというものがもしあるんだったら
インターネットエクスプローラーの処理をするみたいな感じで
同じことをする処理を書いてるはずなのに
ブラウザーごとに異なるコードを書かなければいけなくなった時代が一時期あったということですね。
1996年の11月になるんですけど
ブラウザー間の互換性問題というのが結構深刻化をしてきました。
ネットスケープ社がエクマインターナショナルに
JavaScriptの標準化というのを提案しました。
これは目的としてはオープンスタンダードにすることで
ウェブ全体の発展というのを促進したいと。
そこからですね、エクマ262という標準化委員会というものが発足しまして
こちらに参加した企業ですけど、ネットスケープコミュニケーションズとマイクロソフト
また提携していたサンマイクロシステム、そしてボーランドですね。
その他、他の関連企業というのも参加しまして、結構名だたる企業が参加されていました。
具体的に人物としてはネットスケープのエンジニアであったブレンダー・アイクですね。
と、マイクロソフトのJScriptチームの一人だったション・カッゼンバーガーという方。
そしてサンマイクロシステム社からは言語設計の専門家であったガイ・スティールも参加されていました。
そこからエクマスクリプト262の第一波の策定というのがスタートしまして
これ1997年ですね。スタートしたんですけど、マイクロソフトというのは自社のJScriptの仕様を主張していまして
ネットスケープはもちろんJavaScriptの仕様を主張していました。
両者の仕様は微妙なんですけどやっぱ重要な違いというのが結構あったらしくなかなかどっちもの主張をちゃんと飲むというのは結構大変だったので
ECMAScriptの普及と進化
結局は妥協点というのを模索せざるを得なくて基本的にはJavaScriptをベースとしていたんですけど一部でJScriptの仕様も採用するという風な方向性に決まりました。
宗教的な議論も実はあってよくあるセミコロンというのを自動挿入するとかこういう細かいところの宗教的な議論も多数発生しました。
このあたりですねさっき出ました3マイクロシステムズのGuy Steeleという方が結構調整能力をフルに発揮しまして何とか標準化成功の鍵となったということですね。
本当たて役者の一人がこのGuy Steeleという方でした。
1997年の6月ついにECMAScriptの262から第1版というのが公開されました。
おめでとうございます。
正式名称はECMAScript Language Specification、仕様という名前ですね。
JavaScriptでもない、そしてJScriptでもない中立的な名前に落ち着いた。
これは基本的な言語仕様というのを定義したものになります。
例えば変数宣言のvarとか関数のfunction、もしくはobject、そして配列のarrayなどその辺の細かな細かな言語仕様というのが最初に定義された感じです。
第1版公開されたんですけどですね、実は結構混乱が起きてしまったと。
標準は策定されたんですけど、既存のブラウザーというのは独自仕様のまま進めておりました。
新しいブラウザーもどんどんどんどん出てきてたんですけど、こちらも完全準拠というのは結構困難だなというふうな判断をされて、やはり独自仕様の実装になってましたと。
開発者としてはブラウザーベンダーがいくつかあるということは、そのブラウザー判定のコードを書く必要があって、それぞれのブラウザー用のソースコードを書かなきゃいけないという大変な時代がありまして。
そこからエグマスクリプト第2版が翌年1998年に出されました。
こちらは主に編集上の修正しかなされていなくて、ISO IEC16262として国際標準化をされたというような形です。
続きまして翌年エグマスクリプト第3版が出ました。
こちらから正規表現の追加ができたり、トライキャッチ分の追加がされたり、またスイッチ分の改良がされたりなどなど、より現実的もしくは実用的な言語に進化をしたというのが第3版です。
そこからちょっと長く冬の時代が続きます。
実は2008年まで続くんですけど、エグマスクリプト第4版がスタートしていたんですけども、これがまさかの挫折をしてしまいます。
というのも第3版が出た1990年の翌年、2000年代の前半ですね、エグマスクリプトの4が策定開始になったんですけど、
この時にクラスベースOOP、オブジェクトオリエンティッドプログラムとか静的片付けとかパッケージシステムなど、結構大幅な機能追加というのが計画されていまして、
あまりにも当時からすると野心的すぎて、結局トンザしてしまうわけですね。
また当時参画していたアドビーですね、アクションスクリプト3.0を出していたアドビー社とマイクロソフト社、そしてモジラ社ですね。
その3社間での意見の対立が結構激化していたというところで、もうエグマスクリプト第4版というのはやめましょうという形になったんですね。
そこから2001年、インターネットエクスプローラーのVer.6ですね。
こちらが圧倒的資格を獲得するように至りましたと。
ほぼほぼ時代としてはIE6というのが取ったという感じで、ウェブ開発もちょっと停滞期に突入してしまう感じになったんですね。
でも一旦ブラウザ戦争がここで収束をしたと言ってみられていました。
そこから時は5年も過ぎましてですね、2005年になります。
AJAX革命というものが出ています。
Jesse James Garrettという方がAJAXという用語を提唱しました。
JavaScriptの初期とライブラリーの発展
技術自体はそもそもあったと思いますけど。
こちらによってGoogleマップであったり、Gmailであったり、
JavaScriptの可能性というのを実証するようなアプリケーションがどんどん出始めましたと。
これは結構記憶に残っている方々もいらっしゃるんじゃないでしょうか。
これによって突然JavaScriptというのが重要な技術として、ウェブ業界としては最強化されていたんでしたね。
そこからさらにライブラリーがいろいろ勃発していくことになります。
2006年、翌年ですね。
AJAX革命の翌年、2006年にJQueryが登場します。
かの天才エンジニアジョン・レシグが開発したライブラリーです。
今でも全世界で使われているライブラリーの一つですし、
一時期はJavaScriptのライブラリーで一番ダウンロードされたライブラリーになります。
今はリアクトが世界一ダウンロードされているライブラリーとなっているはずですけど、
それまではJQueryが一番だったんですね。
これを代表として他にもPrototype.jsとかMootoolsとかDojoみたいなライブラリーがたくさん出始めまして、
ECMAScriptの進化
お互いに競争していましたと。
この辺の名前も記憶に残っている方もいらっしゃるんではないでしょうか。
これらはですね、ブラウザの差分というのをうまいこと吸収して、
JavaScriptをより使いやすくしたようなライブラリーになります。
このライブラリーごとにシェアの奪い合いもちょっとしてたって感じです。
そこからですね、また時は流れまして、
ECMAScript第5版がスタートします。
これは2009年ですけど、
ECMAScript第4版の反省を踏まえまして、
段階的な改善に方針転換をしたという感じで、
第5版ではStrictモードの導入がされたり、
JSONをサポートするようになりました。
また、回列メソッドとして、
ForEachとかMap、そしてFilterなどなど、
回列メソッドというのが追加になりました。
あとはプロパティ記述詞として、
GetterもしくはSetterというものが追加になっています。
こうやって聞くと結構、
現代のホログラミング言語に近づいてきたという感触はありますよね。
また、この辺からですね、
ブラウザーベンダーが結構強調するようになったんですね。
Firefoxを作っていたModular、
そしてSafariを作っていたApple、
Chromeを作っていたGoogle、
iを作っていたMicrosoft。
より実装しやすく、
そして互換性を重視した仕様というのを目指して、
強調するようになってきたんですね。
これ結構大きい流れだったと思います。
そして時は6年も流れまして、
大浜田アップデートがなされます。
こちらもやっぱりES4の失敗を踏まえつつ、
また新調、そして段階的なアプローチを取ってきました。
プロジェクト名としてはHarmonyという名前のプロジェクト名として、
開発が進められておりまして、
当初の予定では2013年のリリース予定だったんですけど、
ちょっと仕様の複雑さからですね、
2年も遅延しまして、
ついにエッグマスクリフトバージョン6 ES2015、
2015年にリリースになりました。
ES6策定の背景とかの話ちょっと続いていくんですけど、
当時ですね、Node.jsっていうのが該当してきました。
該当したプラス混乱もしてましてですね、
これが2009年、
ライアンダールっていう方がNode.jsを発表したとき、
彼はですね、
実は最初Rubyを使おうとしていたらしくて、
なんですけど、
Rubyの既存エコシステムっていうのが
ブロッキングIOを前提としておりましたため、
ちょっと思想が違いまして、
V8とJavaScriptっていうのを選択した形になります。
この選択が皮肉にも、
ちょっとJavaScriptにも大きな問題をもたらしてしまいますと。
Node.jsではCommonJSというモジュールシステムが採用されていました。
まあこの辺は皆さんもご存知と思います。
これはIzargSkeletor、
ちょっと読み方すいません、
もう間違ってた、ごめんなさい。
後のNPMの作成者の方ですけど、
この方らが中心となって設計したもので、
サーバーサイドでの使いやすさというのを重視しておりました。
ブラウザーではAMD、
Asynchronous Module Definitionというのが主流になっていて、
代替言語と新技術の登場
James BurkeのRequire.jsというのが事実上の標準になっていました。
この分裂によって、
同じJavaScriptでも、
サーバー用のコードとブラウザー用のコードというのが
全く異なる形式になってしまいました。
NPMのパッケージ数は急成長していたんですけど、
2011年に1000個、
そして2013年には5万個ということで、
爆発的に増えていたんですね。
その多くがサーバー専用のものだったんです。
ブラウザーでは使えないような状況だったんですね。
そこから時山の流れで、
GoogleのV8エンジンというものが、
JavaScript界に結構衝撃を与えたものでした。
Lars Buck、元サンマイクロシステムズの
HotSpot JVMの開発者の方ですけど、
こちらの方が率いるチームというのが、
JIT Compileと最適化技術によって、
JavaScriptを10から100倍高速化しました。
この成功によって、
他のベンダーも追随せざるを得なくなりまして、
Modularはブレンダン・アイク自身が
陣頭式を取って、
スパイダーモンキーエンジンの大改革を実施しました。
一方Apple社はですね、
SafariのJavaScriptコアを
密かに大幅改良しておりましたと。
そんな風に各ベンダーが動いてたんですけど、
興味深いのはマイクロソフトの動きだったんですね。
IEチームは長らくJavaScriptを実は軽視していたんですよ。
もともと彼らはJScriptを作ってましたから。
なんですけど、
Chromeの躍進を見て、
正直ちょっと慌てふためいたんじゃないかな
という風に見受けられます。
で、チャクラエンジンの開発CMというのは、
ES6の仕様が固まる前から
結構先行実装をスタートしておりまして、
で、マイクロソフトこそが
最先端というところをアピールしを通していましたと。
ここからちょっと視点を変えまして、
当時、開発者の不満があったり、
結構代替言語というのが勃発していたんですよ。
例えばその一つとして、
コーヒースクリプトというものが出てます。
皆さんも使ったことある人も結構多いんじゃないでしょう。
コーヒースクリプトの革命と、
ジェレミー・アッシュ・クナスという方、
ジェレミー・アッシュ・クナスと一体読みます。
この方の野望が2009年ありまして、
Underscore.jsの作者の方ですけど、
この方はJavaScriptに強い不満を持っておりました。
彼は、JavaScriptは素晴らしいアイディアは多いんですけど、
公文がちょっと醜すぎますねという風に講言をしていて、
RubyとPythonの美しさというのを
JavaScriptにもたらそうとした感じです。
実際、コーヒースクリプトの成功というのは結構凄まじくて、
2011年頃にはGitHubでJavaScriptよりも
コーヒースクリプトのプロジェクトの方が
多い日もあったぐらい伸びてたんですね。
レールズコミュニティというのは、
コーヒースクリプトを標準採用して、
37signals、現ベースキャンプ、
これも読み方というかわからないですけど、
のDavid Heinemeyer Hansonという方が、
JavaScriptは書きません。
コーヒースクリプトしか書かないという風な宣言をされていたと。
これ結構強い宣言ですよね。
それぐらいコーヒースクリプトに投資をしていた感じですね。
この状況にTC39、テクニカルコミッター39というやつで、
エクマスクリプトの使用を決めていた
専門的な委員会の方ですけど、
39というのは管理番号39ということです。
このTC39のメンバーは強い危機感というのを抱いていました。
もしかしたらJavaScriptが見捨てられるんじゃねえか
みたいな恐怖がありまして。
で、ES6の開発を加速させなきゃいけないという、
これ結構原動力になった話です。
また、Microsoftというのがタイプスクリプト戦略として、
Anders Helsberg、Cシャープの父の方だそうですね。
この方が率いるMicrosoftタイプスクリプトチームの戦略というのが
結構巧妙だったらしく。
JavaScriptを批判するんではなく、
JavaScriptは素晴らしいんですけど、
大規模開発では型がやっぱ必要だよねっていうようなメッセージで
開発者の支持を集めました。
さらに重要なのは、
タイプスクリプトがES6の機能を先取りして実装していたことにありますと、
いわゆるクラス構文とか、アロー関数、そして分割代入などなど、
これらをブラウザーが対応する前から使えるようにしていたんですね。
これによって、ES6を待つよりタイプスクリプトを使えばいいという流れが生まれまして、
TC39にとって大きなプレッシャーになってしまったんですね。
また、GoogleのDartという言語とAdScriptというもの、
この2面戦略をGoogle内部ではJavaScriptに対する見方が分かれていたと。
ChromeチームはJavaScriptを推進していたんですけど、
JavaScriptの限界と代替案
言語設計チームというのは、JavaScriptは根本的に限界があるよというふうに考えておりました。
ラースバックが率いるDartチームというのは、
JavaScriptの完全な置き換えというのを実は目指していたんですね。
一方、Google社が作っていたJavaScriptのフレームワーク、Angular。
Angularチームというのは、このAdScriptというタイプスクリプトベースの言語を開発していたんですね。
Google内部でも、JavaScriptを見限るのかどうかというところについて激しい議論が行われていて、
その情報はTC39にも断片的に漏れていたりしたという感じです。
この状況について、ブレンダーイクは後に2012から2013年というのは、
JavaScriptの存在を懸けた戦いだったというふうに振り返っております。
さらに、TC39の内部事情の話に繋がるんですけど、
委員会メンバーに複雑な関係セットができてしまいました。
TC39は表向きという技術的な議論を行う場だったんですけど、
実際は各企業の思惑とかが複雑に絡み合うような政治的な戦場になってしまいました。
委員会の複雑な内部事情
委員長であったブレンダーイク、本当に彼は何でもやりますね。
彼はJavaScriptの産みの親として強い権威を持っていたんですけど、
同時にModularという1企業の利益代表でもありました。
マイクロソフトのアレン・ワーフズ・ブロックという方が非常に興味深い人物で、
彼はもともとSmalltalk80の実装者で、
オブジェクト思考の設計に深い知見を持っていた方でした。
マイクロソフトの社内では、なぜ競合他社の言語の標準化に協力するのか、
という批判に彼は晒されておりまして、
標準化に参加することで、マイクロソフトの技術的プレゼンスが示せる、
と社内を説得し続けていたんですね。
またまた、委員会の別のメンバー、デイブ・ハーマン、これはModular社の方ですけど、
彼はもともと学者でおりまして、プログラミング言語理論の専門家でありました。
彼はES6のモジュールシステムの設計を任されておりましたが、
学術的に正しい設計と実用性の間で苦悩をしておりまして、
特にNode.jsのCommon.jsとの互換性をどこまで保つかというところで、
激しい内部議論というのもありましたよと。
こんな感じで、結構委員会メンバーにも複雑な関係性というのが生まれてしまった。
またですね、ここから企業間の隠された対立みたいなところにちょっと触れていくんですけど、
まずはModular vs Microsoftのクラス交文戦争というものですね。
今ではもうクラス交文、シンタックス集会ではあるんですけど、書けるというのは皆さんご存知のとおりですけど、
クラス交文の議論というのはJavaScriptの設計思想そのものに関わる結構根本的な対立だったんですよ。
Modularのブレンダー・アイクは、いつの間にかブレンダー・アイクはヘッドスケープからModularに移ったんですね。
ブレンダー・アイクは、JavaScriptというのはプロトタイプベースであることに意味がある。
クラス交文はJava開発者への媚びに過ぎないというふうに強く主張していた形ですと。
一方、Microsoftのアレン・ワーフズ・ブロックという方は、
現実的に考えれば、企業でのJavaScript採用にはクラス交文が不可欠。
理想論ではJavaScriptは生き残れないというふうに反論をしたと。結構強い反論ですね。
この議論は2011年から2013年まで2年間も続き、時にはとても激しい口論になることもあったらしいですね。
転機となったのは、Adobeの貢献だったらしいです。
Adobeはアクションスクリプトを3.0でクラスベースのOOPを採用していたのですが、
Adobeはアクションスクリプトの知見をES6に活かしたいという提案をしていました。
アクションスクリプトのクラス交文は内部的にプロトタイプベースで実装されており、
見た目はクラス、中身はプロトタイプという妥協案の実現可能性を証明していました。
これはもう皆さん疑似感ありますよね。現在のJavaScriptの仕様だと思います。
GoogleのV8最適化圧力事件というのが2012年に起きていまして、
GoogleのV8チームがTC39に対してパフォーマンスを損なう仕様は受け入れられないというような強硬な要求を出しておりました。
特に問題となったのはブロッキシーオブジェクトの仕様で、
V8エンジニアはこの仕様では最適化が不可能というふうに主張をしておりました。
これに対してModularのJavaScriptエンジニアというのは、
Googleは自社エンジンの都合を標準に押し付けようとしているというふうに猛反発をしました。
AppleのJavaScriptコアチームも最適化の困難さは実装者の努力で解決すべきとして、
Googleに反対しておりました。
Adobeの貢献とエンジンベンダーの影響
この対立は結構深刻な問題でして、
一時期はGoogleがTC39から発大するんじゃないかみたいな噂も流れていて、
最終的にはプロ機種の仕様を段階的に導入するところで妥協案が成立しましたと。
この事件によってエンジンベンダーの力関係というのがTC39の議論に大きな影響を与えてしまうことが
公になってしまいましたよというところです。
というところで、まだまだES6の話続きたいんですけど、
まだちょっと長くなりますので今回はここで区切りまして前後半にしたいと思います。
はい、ちょっと突然で申し訳ないですけど、また後半もお楽しみにしていただければなと思います。
それではエンディングトークです。
はい、今までエクマスクリプトの歴史知ってるようで全然知らなくて、
ちゃんと調べたらわりかしいろんなドラマが入ってて、
どんなものにも歴史がありドラマがあるっていうのを改めて認識させられるお話だったんですけど、
僕はやっぱり人の歴史すごく好きで、日本史も世界史も実は好きなんですけど、
いろんなツールの歴史を見ていくと、会社の思惑であったり、人の思想であったりとか、
元々の開発者の思惑とかもあったりして、その辺のバッティングからどういうふうに落とし所をつけて、
その結果どういう言語とか仕様になったのかっていうのが今の形に出てくると。
その言語の今の仕様からリバースエンジニアをしてどういう思想なのかっていうのがある程度予想つきますけど、
ちゃんと調べてみるとその予想と実際の現実の思惑っていうのがリンクしたり、
または相反するものもあったりするんですけど、
そういうのを知ることができて、なかなかそれはそれで僕は面白かったなと思います。
まあでも標準化の流れっていうのができたというのはJavaScriptの歴史の中ではとてもいい話でありますし、
後半もしゃべりますけど、今後もESの進化、そしてJavaScriptの進化っていうのは追っていきたいと思います。
僕のやっぱ大好きな言語でもありますのでね。
まあでも今のES6、一応ES2025になるんですかね、今はもう。
厳密に言うとESじゃなくてJSになるかもしれないですね。
JS2025、まだ出てないかな。
一応公式サイト見たんですけど、JS2024かな、までは出ていまして。
いわゆるセマンティックバージョンアップをするっていうのがもう今決まってますのでね。
JS2024まで出ているということで、今後もJSはどんどんどんどん進化していくんですけど、
この番組でもちょこちょこ触れていこうかなと思っておりますので、興味があればまた来てみてください。
はい、それではこんなところで終わっていきたいと思います。
クロージングです。
この番組面白かったよという方はぜひチャンネル登録もお願いします。
もし聞いていて気になることや話してほしいトピック、感想などございましたら、
概要欄のフォームやXでハッシュタグ、web小話でつぶやいてください。
webはアルファベット、小話は漢字でもひらがなでも大丈夫です。
今回もお聞きくださりありがとうございました。
甘えどれをしながら考える技術の変遷。
次回もどうぞ楽しみに。
お相手はキースでした。さようなら。
今日も喋ってるそこのあなた。第2回ポッドキャストスターアワード2025開催中です。
雑談でも語りでもゆる配信でもあなたの声応募してみませんか。
対象には10万円ほか豪華特典も。
詳しくはpodcaster.jpをご覧ください。
ナンバーワンポッドキャストクリエイターは誰だ。
