ECMAScriptの初期開発
雨宿りとWEBの小噺、パーソナリティーのkeethこと、上原です。この番組では、今苦しく変化するWEB業界の中、ちょっと一息つける裏話や小噺などをお届けします。
今回は、ECMAScriptの誕生秘話や歴史の後編となります。
とても長い回で、前回もすごく長かったんですけど、今回も情報盛りだくさん、お話盛り盛りなので、ゆっくりお楽しみいただければなと思います。
特にES6のお話は、かなり裏話があって面白いので、ぜひお楽しみください。それでは本編をどうぞ。
ではここから、主要作というのを舞台裏で、結構面白い展開について見ていこうと思います。
ちょっと時間を遡りまして、2011年ハーモニープロジェクトというもののお話です。
ES4の失敗を受けてTC39はハーモニー、まあ調和っていう英単語ですね。
ハーモニーという名前で、新しいプロジェクトというのを開始しておりました。
この名前には、企業間の対立を乗り越えて強調するという願いが込められていましたが、現実は理想とはほど遠いものになってしまいました。
各企業は、表向きが強調というのを謳っておりながらも、水面下では自社に有利な仕様の採用というのを目指しておりました。
特に、マイクロソフトはES6をWindows8のリリースに間に合わせたいという強い要求があって、スケジュール最優先というのを主張しておりました。
ブレンダーイクは当初、ES6というものをJavaScriptを大人の言語にする最後のチャンスというふうに位置づけていて、
彼はJavaScriptの誕生から15年以上経っても、いわゆるおもちゃ言語とみなされていることに強い不満を持っていて、
JavaとかCシャープでは負けない本格的な言語にしたいというふうに野心を抱いていました。
2012年、ES6の使用書というのはすでに400ページを超えていたと。すごいですね。
実装の複雑さというのも結構懸念されておりました。
アレン・ワーフズブロックというのはこれは明らかに大きすぎる。
ES6とES7に分割すべきじゃないのか、みたいなふうに提案をしていまして、
この提案に対してまたまた激しい議論が起こりまして、
Modularのデイブ・ハーマンは、分割すると機能間の整合性が取れなくなってしまう。
特にモジュールシステムとクラスコーブンというのは密接に関連しているというふうに反対をしております。
一方で、ブラウザーベンダーからは、このサイズでは実装に3年から4年ぐらいかかってしまう。
その間にJavaScriptが時代遅れになってしまうという懸念も出ておりました。
また、Chromeチームのエリック・アービットソンという方は、
Google内部ではJavaScriptへの疑問の声も出ている。
あんま遅くなると経営人がダートへの移行を決断するかもしれないというふうな警告も出しております。
結局、ES6の主要機能というのは維持されて、ES7では細かい改善に留めるという方針で決着をしました。
が、この議論によってES6のリリースが1年ぐらい遅れることになってしまいます。
ES6の実装課題
続いて翌年、2013年ですけど、各ブラウザーベンダーからES6の実装が予想以上に困難という報告が相次いまして、
深刻だったのは仕様書の曖昧さですよ、と。
例えば、クラス構文の継承に関する記述で、
スーパークラスコンストラクターの呼び出しのタイミングについて、仕様書では3行しか説明されておりませんでした。
しかしですね、実際に実装しようとすると、エラーハンドリング、メモリー管理、パフォーマンス最適化などなど考慮すべき点が山のようにありまして、
モジラーのジェイソン・オーランドルフ、スパイダーモンキーの主要開発者は、TC39の会議で、
仕様書は理想的すぎる、実装者の苦労を理解していない、というふうに厳しく非難しました。
これは結構納得いきますよね。誰のための仕様だり、誰のための言語なんだっていうところにたどり着きますもんね。
で彼は、このままでは2015年リリースというのは不可能だというふうに警告をしております。
でこの状況を受けて、TC39は異例の実装優先方針に変換をしますと。
で仕様書の記述よりも、実際に動く高度というものを重視し、複数のエンジンで実装可能な仕様に修正していくことにしたんですよ。
で続いて2014年、翌年ですね。セバスチャン・マッケンゼィっていう方が、天才的発想で、
当時17歳だった方なんですけど、彼がオーストラリアで6to5というプロジェクトを開始しました。
ES6のコードをES5に変換するという、トランスパイラーを書いたんですね。
でセバスチャンは、グラウザの実装っていうのは待ってらんないよと。
ES6の機能を今すぐ使えるようにしましょう、という発想で開発を始めていて、
驚くべきことに彼はES6の仕様書を読み込み、わずか数ヶ月で主要機能のトランスパイルっていうのを実現しちゃったんですよ。
今みたいに生成アイドルがあるわけで、彼自力でやったってことですね。衝撃です。
で実際TC39メンバーも衝撃を受けて、方針転換をすることになるんですね。
で6to5からの解明のこと、いわゆるバベルっていうものが後に解明されたんですけど、
このバベルの完成度っていうのはTC39メンバーにとっても衝撃でした。
いやバベルは本当に時代築きましたよね。皆さんもだいぶバベル使ったことあるんじゃないでしょうか。
17歳の少年が個人で作ったツールっていうのが、まさか我々が3年かけて議論している仕様を実装しているという現実に直面をした。
こっちにショックを受けたと思います。
さらにですね、驚くべきことにバベルの実装によってES6仕様の問題点っていうのが次々と発見されてしまいましたと。
いや面白い話です。 例えば、
分割代入の仕様には循環参照の処理に関する重大な欠陥がありまして、
バベルでの実装テストによって初めて明らかになってしまいました。 例えばこんな感じで問題が見つかってしまったよということですね。
実際ブレンダーイクもバベルはES6の事実上の参照実装になったというふうに認めていて、
TC39はバベルでの実装を仕様策定の重要な指標として採用することになりました。
クラス構文とディスの問題
これは標準化団体が外部の実装を公式に参考にするという極めて異例の決定だったんですね。
いやーこれ結構当時のメンバーからしたら衝撃だったでしょうね。
はい。 ちょっと話はですねクラス公文に戻ってしまうんですけど、
ブレンダーイクの根本的な反対、実はクラス公文の導入に最後まで反対していたらしいです。
彼は2012年のTC39の会議で、 クラス公文というのはJavaScriptのDNAに反してしまう。
これはJavaへの屈服だみたいな感じで激しく主張していたんですね。 ブレンダーイクの主張には深い哲学もありましたと。
JavaScriptのプロトタイプベースはセルフという言語から受け継いだ革新的な設計であります。
クラスベースは古い考え方でJavaScriptが持つ柔軟性というのを殺してしまうというふうに主張していましたと。
具体例として、 jQueryのプラグインシステムがプロトタイプの柔軟性によって実現されていることを挙げております。
興味深いことに、コーヒースクリプトの作者ジェレミー・アシュゲナスがクラス公文の推進派になったんですよ。
彼はTC39にゲストとして招かれた際、 コーヒースクリプトでクラス公文が人気なのは開発者が本当に求めているからだよと。
JavaScriptが提供しないなら我々コーヒースクリプトが提供するというふうに発言しました。
この発言はTC39メンバーにまたまた大きなインパクトを与えまして、
大体言語に先起こされているという危機感がクラス公文導入への流れを決定すげました。
この時にも既にJavaScriptという言語そのもののポジションとか立ち位置が危うくなったということを意味しているとも捉えられますね。
アドビ、アクションスクリプトからの教訓ですけど、最終的にクラス公文の採用を決めたのはアドビの貢献だったよ。
アクションスクリプト3.0の設計者、エドウィン・スミスという方は、
アクションスクリプトでは見た目はクラス、中身はプロトタイプというのを実装している。
パフォーマンスも柔軟性も両立できるというふうに実証しました。
アクションスクリプトのアプローチは結構巧妙でして、クラス公文はシンタックス主がに過ぎない。
実際の動作というのはプロトタイプとチェーンと同じでした。
これによってクラス公文を使いたい開発者と、プロトタイプの柔軟性を求める開発者の両方というのを満足させることができますよ。
さらに、JavaScriptのディスというバインディングの話につながります。
こちらは1995年の設計時から開発者を悩ませ続けていたらしいディスバインディングというものは。
ブレンダーイクは後に10日間で作った時に最も公開しているのがディスの動作だというふうに語っております。
特に深刻だったのはイベントハンドラーとかコールバック関数でのディス問題ですね。
JQueryの開発者たちはこの問題を解決するために .bind というメソッドだったり $.proxy という関数を作りましたけど、
まあ根本的な解決にはならなかった。
コーヒースクリプトのアローですね。
アロー公文というのは多くの JavaScript 開発者にこんな書き方できたらええのになぁというふうに思わせていました。
ジェレミー・アシュケナスというのは意図的に JavaScript の至り点をつく公文というのを設計していたよと。
いやーこの辺はなんかもう作戦価値感があります。
またアロー関数の設計の話になりますけど、省略記法 vs ディスバインディングのどちらを主目的にするかで議論が分かれておりまして、
Modular の Jason Orendorf は、
単なる省略記法なら必要ないディス問題の解決こそが本質だというふうに主張しております。
最終的にアロー関数というのはレキシカルスコープのディスというような革新的な動作が採用されました。
これは JavaScript のディスルールに新たな例外を追加することを意味していて、
言語の一貫性を損なうというようなリスクもあったんですね。
しかし実用性というのが今は大事だということでこれが採用されました。
ではここからはバーの根本的欠陥によって20年近く開発者が苦しむことになりました。
その話をしようと思います。
バーのスコープの話と聞くと皆さんある程度想像はつくと思います。
バーのスコープ地獄と言ってもいいでしょう。
変数宣言の複雑さ
JavaScript には元々 var ですね。変数宣言をする var というものがありまして、
これの動作というのが C 言語のスコープルールというのを誤解して生まれたものだったらしいです。
ブレンダーエイクは当時、ブロックスコープは実装が複雑だから関数スコープにしようと安易に決めてしまってらしいですね。
この決定によって20年間にわたって開発者が苦しむことになってしまいました。
特に for ループでの問題というのが深刻で、JavaScript あるあるとして多くの開発者が体験したんじゃないかなと思っています。
ちょっと伝わるかわからないですけど、例えばフォードを今から口でしゃべりますけど、
for 文ですね。for のバー i イコールゼロの i は 3 までの i プラスプラスで中に setTimeout を押して、
コールバック関数として無名関数ファンクションで中身 console.log の i をつけておく。
第2引数に100ですね。100ミリ秒で setTimeout しましょう。
これで console.log i って何が出るかというと、for 文回しているので期待値としては 0,1,2 が出るはずなんですけど、
結果としては、 console.log の i は全部 3 が出力されてしまう。
皆さんも手元でちょっと試してみていただければと思います。全部 3 が出力されるはずですね。
ES6 以前の苦肉の策として、開発者たちはバーの問題を回避するために様々な技法を編み出しておりました。
最も有名なのが iife って言われるもの。
Immediately Invoked Function Expression っていうパターンです。
バンドラーとかビルドツールを使ってビルドした後に出てくるファイルの形式ですよね。
AMD とかありますけど、それの中の一つに iife というものもあります。
このパターンは非常に有効だったんですけど、なぜこんな複雑なことをせなあかんのかという不満が開発者にも蓄積をしていた。
じゃあっていうので、変数宣言 Red と Const っていうものが誕生するんですけど、
それの設計についてはまた激論があったらしいってですね、調べた感じ。
Red Const の設計では既存コードとの互換性が最大の論点だったらしいです。
マイクロソフトの アレン・ワーフズ・ブロック っていう方が、バーを非推奨にして Red Const に移行すべきというふうに最初主張をしておりました。
しかし、Modular の デイヴ・ハーマン っていう方が強く反対をしています。
既存の JavaScript コードは膨大で、バーを非推奨にすると Web が壊れる。
互換性を保ちながら新しいスコープルルールを導入する方法を見つけるべきだと主張したのです。
こちらもそりゃ言い分は正しいと思いますね。
できれば今の Web を壊さないで新しいルール・機能を追加できれば一番いいと思っています。
緩やかにもうみんな使わないだろうみたいなタイミングを見計らって、一気に非推奨にする、デプリケートにするっていうのがいいんじゃないかなと思いますね。
最終的には厳密モード、ストリクトモードっていうものが実装されて、
こちらで RedConst っていうのは推奨し、非厳密モードではバーも使えるというような妥協案が採用されましたという形に落ち着いたところですね。
モジュールシステムの分裂
ではでは続きましてモジュールシステムです。
Node.js vs ブラウザーの大統一の構想の話です。
Node.js ってワードが出てきたり、モジュールシステムってワードが出てくるということは、コモンJSの話ですね。
コモンJSと AMD の分裂ですけど、Node.js のコモンJSとブラウザーの AMD の分裂というものは、JavaScript コミュニティに結構深刻な分断をもたらしてしまいました。
npm のパッケージはサーバー専用、Require.js のモジュールはブラウザ専用という状況でした。
アイザック・シュルーター、npm 作者の方ですけど、この方はコモンJSこそが JavaScript の未来、ブラウザーがコモンJSに対応すべきだという風な主張をされていました。
一方、ジェームズ・バーク、こちら Require.js の作者の方は、ブラウザーの非同期環境では AMD が最適、Node.js が AMD に対応すべきと反論していました。
もう一本譲らなかった感じですね、お互いが。
で、もう一人、レイヴ・ハーマンですけど、こちらが野心的な統一案を出したんですね。
モジュラーのレイヴ・ハーマンも何度も出てきましたが、この分裂を解決する野心的な提案というのは ES6 モジュールではコモンJSと AMD の両方と互換性を保ち、さらに静的解析も可能にするという欲張りな設計を主張したんですね。
いやもう本当いいとこ取りかつ盛り盛りなって感じですけど、 ES6 モジュール図の統一構文としては、importfs from fs モジュール図ですね。これはコモンJS風ですと。
import並括語の readfile from fs っていうのは分割代入。
export default class myclass保存ゲームっていうのが AMD の Define Sort。
で、ラスト export 並括語で、Helper 1、Helper 2 みたいなもの。これは複数エクスポートというような形です。
見慣れた形なので結果はこれに落ち着いたってことですよね。
しかしですね、ES6 モジュール図の実装は予想以上に困難を極めまして、 特に既存のコモンJSモジュールとの互換性が大きな問題となりました。
node.js の既存エコシステムをどう扱うかということで、もう本当これだけで2年以上議論が続いたんですよ。
最終的に ES6 モジュール図は理想的では実装困難な仕様となってしまい、 実際の普及には ES6 リリース後も長い時間がかかってしまいました。
まあでもそういう形で着地はしたという感じですね。 すごい野心的ではあったんですけど結局はここに落ち着いた。
Promise とジェネレーターの進化
ではでは続いての構想です。 本当に ES6 周りはいくらでも話題学校とかがあるんですけど、
次は Promise です。 コールバック時刻からの解放の話。
JQuery Deferred の予想外の影響という話をちょっとするんですけども、 Promise の標準化に大きな影響を与えたのが実は JQuery の Deferred オブジェクトだったんですね。
ジョン・レシグ、JQuery の作者ですけど、この方が 2011 年に Deferred を導入し、多くの開発者が非同期処理の新しい形っていうのを体験しました。
同時期に JavaScript コミュニティでは Promise A プラスという仕様が草の根で開発をされていました。
ちょっと僕これ調べて初めて知ったんですけど、ドメニック・デニコラとブライアン・キャバリアーという方々が中心となって、真の Promise とは何というのを定義していったらしいです。
興味深いことに JQuery の Deferred は Promise A プラスの仕様に準拠しておりませんでした。
これによって JavaScript コミュニティでは JQuery Promise VS 真の Promise という論争が発生しておりました。
いやこれも結構派閥強そうですよね。
で ES6 Promise の政治的判断が下るんですけど、TC39 は ES6 Promise っていうのはどのように従うべきかという重要な判断を迫られまして、
JQuery は既に数百万のサイトで使われており、互換性を考えれば JQuery の仕様に合わせる方が現実的ですよねっていうのが想像上に硬くないと。
しかし TC39 は技術的正しさっていうのを今回選択して Promise A プラスに準拠した仕様っていうのを採用してしまったんです。
これによって ES6 Promise と JQuery の Deferred には互換性がなくなってしまったんですが、長期的には結果良い設計となったっていうような形になります。
これ僕結構英談だと思っていて、やはり TC39 はそういう現実もしっかり考えなきゃいけないんですけど、
企画というか標準を謳う組織、委員会ですので、そこは技術に準拠していくっていう姿勢は私は好感触ですね。
何のための技術なんだって話はあると思うんですけど。 続いて、Promise が出てきたということは、
エーシンカーウェイトの実験状と、あとジェネレーターの話がちょっと続きます。 またまた出てきます、デイビッド・ハーマンですけど、ほんと野心家なんですけど、
ジェネレーターの設計を主導したのがこのモジュラーのデイビッド・ハーマンで、実は強調的マルチタスキングという壮大な理論を JavaScript に持ち込もうとしておりました。
これは学術的には美しい概念だったんですけど、ちょっと僕はここまだ見てないんですが、 実用性というのは結構疑問されていたらしいですね。
ジェネレーター、あれをちゃんと美しいと思えるかどうかは、結構理解の深さによります。
ジェネレーターの真の価値を発見したのは、 Node.js コミュニティの TJ Holloway Chuck という方だったそうです。
彼は co.js というライブラリーでジェネレーターを作って、 同期風にかける非同期処理というのを実現したと。
ソースコードはあるんですけど、ちょっと長くなるし、これ言葉で伝わりづらいので省略します。
この co.js のパターンが後の Async Await の直接的な実装となりました。
ジェネレーターは理論的な美しさよりも実用的な非同期処理の方向で進化していったのです。
こちらはなんと実用面の方に傾いたらしいですね。
見た目、Yield を使っているので、確かにこれ Async Await ほぼ co.js をパクッタに近い感覚ですね。
そんなこんなで、いろいろ思想と構想があって、現実的と理論的な美しさ、どっちも傾いたものだったりするので結構ガチャガチャした仕様なんだなっていうふうに見えても仕方ない気がします。
では続いて、特大テーマ、ブラウザー実装の競争の舞台裏の話についに入っていきます。
まずは Chrome V8 の先行戦略ですけど、
Google Chrome チームは ES6 実装で他を圧倒する戦略を取ってきております。これは今もそうだかな。
ブラウザーの競争とES6の実装
ラースバックが ES6 実装でブラウザー戦争の主導権を握るというふうに宣言をしていた。
それに対して開発リソースも大幅に投入をしていました。 Chrome は hyphen hyphen harmony というフラグで実験的機能を提供し、
開発者に Chrome が最先端というような印象を与えることにある程度成功したと言えます。
この戦略は非常に効果的で、多くのウェブ開発者が Chrome を主要な開発環境として選ぶようになってきたと。
実際今も全世界で一番使われているブラウザーではなかったかな。
続いて Firefox、スパイダーモンキーの技術的プライドの話で、
モジラは JavaScript の生みの親として技術的に最も正確な実装を目指している。
これも僕もそうだなと思うので、もし安定したブラウザであり、JavaScript を安定した環境で実装したいんだったら、確かに Firefox が僕もいいなと思っている派です。
これはブレンダー・アイク自身も実装レビューに参加をして、使用書の曖昧な部分については TC39 に積極的にフォーアヒードバックを送ったそうです。
Firefox の Red Const の実装は他のブラウザよりもちょっと早く、技術的にも最も正確に実装されたらしいです。
しかし Chrome の積極的なマーケティングに押されてしまって、開発者の注目度ではちょっと劣ってしまったという感じです。
難しいですね、これまた。結果、マーケティングしてユーザーを勝ち取った人が強いというのはその通りだなという感じです。
じゃあ続いてのブラウザ、Safari ですね。 JavaScript コアの独自路線ですけど。
Apple は ES6 の実装において他とは異なる独自のアプローチを取ってきたという形です。
iPhone や iPad での省電力性能というのを最重視しており、ES6 機能というのは完全に実装してから公開するというような慎重な方針を取っていたと。
この方針によって、Safari の ES6 の対応は他よりちょっと遅くなってしまったんですけど、リリースされた機能は非常に安定しており、特に iOS の JavaScript 性能は ES6 対応後も電池寿命に大きな影響を与えませんでしたと。
フレームワークの進化
これ結構デカいですね。確かに iPhone で JavaScript の性能によってバリバリに電池食われたら、ユーザーからしたらたまったもんじゃないですからね。
はい、で続いてメジャーブラウザ、ラストバー、インターネットエクスプローラー、エッジの復活劇ですね。
マイクロソフトの IE チームは長らくウェブ表情には消極的でしたが、ES6 では一転してすごい積極的になってきたと。
新しいエッジブラウザでは一部の ES6 機能で他を先行することさえありましたと。
特に印象的だったのは、マイクロソフトが ES6 実装の進捗を公開ダッシュボードで透明化したことになりますと。
これによって、マイクロソフトが変わったなっていうような印象を開発者に与えることに成功しましたよ。
エッジ出た時、しかも途中でクロミウムになりましたからね。
これ本当変わったなって僕も感じました。
最初は IE モードっていうものが実装されていて、全然 IE の中央を引き継いでんじゃんって思ってたんですけど、
最近のエッジブラウザは全然違うなっていう感触ですね。
では ES6 リリースした後の話をしていこうと思います。
リアクトコミュニティの全面的 ES6 化の話から入ります。
現在メタ、当時はフェイスブックですね。
リアクトチームは ES6 のリリース後、いち早く全面的な ES6 化っていうのを進めておりました。
皆さん大好きダン先生とかセバスチャン・マーク・ベイジが主導して、
リアクトのコード例とかドキュメントを ES6 に統一をしていったんですね。
この変化は結構劇的で、リアクトコミュニティが ES6 普及の大きな推進力とその中になっていた。
これはこれでいい話だったなと思います。
続いて Angular 2 と言うと怒られそう。
正しくはアンギュラー。
バージョン 1 の時のことをアンギュラー・ジェースと言って、
今のフレームワークのことをアンギュラーというのが正しい発音だったと記憶してます。
Google の Angular チームですね。
こちらも ES6 そして TypeScript を前提としたフレームワークになっておりまして、
全バージョンの互換性をもう完全に断ち切ってしまいました。
もう完全に新しいフレームワークとしてになります。
ミスコ・ヘベリー、アンギュラーの作者の方、一人ですね。
その方は ES6 なしでは現代的なフレームワークはもう作れないというふうに宣言をしておりました。
この決断は賛否両論を呼びましたけれども、結果として、
アンギュラーはリアクト並ぶモダンフレームワークの地位を確立しましたと。
Node.jsと標準化の改革
これは本当そうですね。
現代の三大 JavaScript フレームワーク、まだリアクトビューアンギュラーだと思ってます、僕も。
続いて、Node.js のエコシステムの大混乱のお話につながります。
さっきも出ました CommonJS vs ES Modules のお話ですけど、
Node.js コミュニティでは ES6 Modules の導入をめぐって激しい議論が起きてましたと。
Node.js 作者の一人、ライアン・ダールという方は既に Node.js から離れていましたが、
ES6 Modules の対応というのは必須だよという立場を表明しておりました。
一方、既存の NPM エコシステムは CommonJS で構築をされており、
移行というのは非常に困難じゃないかなと。
アイザック・シュルターは NPM の 50 万のパッケージをどうするのっていう問題の深刻さを指摘しておりましたと。
で、最終的に Node.js チームが採用したのは、パッケージ JSON で明示的に指定するという解決策だったそうですね。
これも出たんですけど、コミュニティを結構二分してしまったと。
意見としては複雑すぎるという批判がある一方で、
広報互換性を保つ唯一の方法だよというような指示もあって、なかなか難しいですね。
パッケージ JSON に、タイプコロンモジュールっていうのをつけるって話でした。
結局今はこの方法になっておりますけどね。
そんなこんなでいろんな議論と放送だったり、批判が出てましたが、
ES6 の限界の話にそろそろ行きます。
ES6 って今言った通りですけど、たくさんの機能が出てきた成果、逆に言うと豊富すぎるため、
JavaScript の学習コストが爆発的に増加をしたよ。
ES6 や ES5 時代は JavaScript は簡単な言語というふうにされており、スタートがそうだったんですけど、
ES6 以降は覚えることが多すぎるという声が高まってきたと。
そこから JavaScript 疲れみたいな言葉が生まれ始めたと。
2016 年頃から JavaScript fatigue っていう、JavaScript 疲れという言葉が海外では横行し始めていて、
ES6 の複雑さに加えて Babel, Webpack, ESLint などのツールチェーンも複雑化してきた感じです。
目的とがそれぞれ違うんですけど。
言語そのものというか、エコシステムを含めて結局開発環境を作るので、これが難しすぎるねという批判が高まってきております。
そしてもう一個、Microsoft が IE11 を最後のインターネットエクスプローラと位置付け、
ES6 対応を限定的にしか行わなかったことで、ウェブ開発者は長きに語って、
IE11 対応っていうのをやらなきゃいけなく、それに悩まされることになってしまいましたよ。
多くのプロジェクトで、 ES6 を使いたいんだが IE11 のために Babel が必要という状況が続いてしまい、
ES6 の恩恵を完全に享受できない期間でも長く続きました。
懐かしいですね。もうフロントエンドエンジニアの方だったらみんな通った道だと思います。
そこに TC39 がプロセスに対してちょっと革命を起こしたと。
ES6 の成功を受けて、 TC39 は標準化プロセスっていうのを根本的に改革しました。
従来の大きなリリースを長期間かけて策定するっていう流れから、
小さな機能を年次リリースにしようというような方向転換をしました。
これ結構革命的なことだったらしいですね。
で、新しいプロセスでは、以下のような段階的な検討が行われるようになりました。
ステージ0でまずアイディア段階として出して、ステージ1でプロポーザル、提案を出します。
ステージ2でドラフトに上がります。
ステージ3でキャンディデート、これで候補に上がる。
ラストステージ4、フィニッシュですね。これで完成です。
このような5つのステップ、プロセスによって機能ごとに独立して検討実装できるようになり、
ES6 のような巨大すぎるリリースを避けるっていうことができるようになった。
ES6 のリリースはさすがにデカすぎましたね。
ここから年次リリースが出た結果、どういう成果になったかというと、
ES2016、ES7ですね。
この時に array.includes と Exponation Operator というのが実装されています。
続いて翌年 ES2017、ES8ですね。
ES8 では asyncは 8、object.entries もしくは object.values というのが実装されています。
翌年 ES2018、ES9ですね。
では rest と spread properties っていうのが入っています。
あとは async iterators が入りました。
続いて ES2019、ES10ですね。
こちらで array.flat ですね。
いやー助かる、array.flat。便利ですよね。
あと object.fromentries っていうのが入りました。
続いて ES2020、ES11ですね。
こちらでオプショナルチェーニングと ヌーリッシュコレッシングというものが入りました。
ヌル合体ですね。
このように毎年着実に機能が実装追加されることで、
ECMAScriptの開発と進化
JavaScript っていうのは継続的に進化をし続ける言語というふうに進化を遂げました。
はい、以上 ES6 の話結構長かったですけど、こんなところでございます。
ということで、今回の ECMAScript の歴史の話は、
区切りとしたいと思います。
現代の ES の話はちょっとまだ調べきれてないのと、
これでも十分長いので、また新たにいろんな更新があったりまとまってきたら、
注目してお話ししてみようかなと思っておりますので、
その時に聞いてみていただければと思います。
それではここからはエンディングです。
いかがだったでしょうか。
いやもう収録実はですね、合計すると1時間半ぐらい喋っていて、
この暇からエンディングトークで含めたら、
100分超えるんじゃないかな、1時間40分超える気がしますけど、
いろんな背景ありますし、特に ES6 はほぼほぼなんかいろんな構想だったり、
皆さんとバッティングの話ばっかりだったんですけど、
そもそも ECMAScript の誕生自体も、
そういう思想と意見と主張と自社のマーケティングとっていういろんな思惑が混ざり合って、
なんとか形になったというところなんで、
なかなかの歴史を見たなって思います。
それで今こういう言語の形になっていて、
完全に美しいとはさすがに言えないなっていう面もあるし、
これは美しいなっていう思想もしくは仕様もあります。
だが特に途中で言いましたけど、
現実的な答えと理論的な美しさと両方が混ざり合った仕様になっていますので、
ちぐはぐ感がある面もそりゃ仕方ないと思いますが、
いろんな意見とかを混ざって落としどころでこうなったということで、
JavaScript、それだけ広くみんなに使っていただける、
簡単に使えるようにするっていうスタートの思想がちゃんとみんなに受け入れられている、
現実になったっていうことの証明でもあるとは思いましたね。
それだけみんなが意見しやすいってことはそういうことだなと思いました。
歴史ざっとまとめますと、
最初はウェーブをもっと動的にしたいというところで、
ブレンダーアイクが指令を受け、
わずか10日間でJavaScriptのプロトタイプを作って、
実際それがそのままスタートしてしまって、
それがまさかの現代でも基本的に保たれているっていうところですね。
名前の変遷としてMOCAからスタートしてライブスクリプト、JavaScriptとなって、
途中でエクマスクリプトが出てきて、
ESX、ES2015みたいなセマンティックなリリースの名前になりました。
そうですね、名前、マーケティングな皮肉もありました。
Javaを使ってしまったけどこれは失敗だったというふうに、
ご本人が言っています。
またまた、ESの歴史上一番大きな切りとなったES6の開発期間が、
偶然だと思いますけど、結局6年間を要して策定されていて、
これはエクマスクリプト史上最長の開発期間だったという、
その分革命的な機能が多数盛り込まれたというので、
これはこれですごかったなと思いますね。
あとは、バベルを作ったセバスチャン・マッケンジという天才ですね。
彼がES6の仕様書を読んで、トランスパイラーを作ったんですよね。
当時まさかの17歳で。
でも彼の貢献なくしてES6の普及というのは、
もっと遅れたんじゃないかなと思っています。
また標準化の教訓として、エクマスクリプトの標準化の過程ですね。
技術標準というのがいかに政治的で困難なプロセスかというのを示す高齢だったんじゃないかなと。
純粋に技術的な議論だけできればそれで良かったとは思いますけど、
もちろんそんなことはなく、
企業間の利害関係、マーケティング戦略、開発者コミュニティの声などなど様々な絡み合いがありましたと言った通りです。
もう結局、現代のJavaScriptの礎とはなったと思います。
ES6というものが。
現在のJavaScriptの立ち位置
今までリアクト、ビュー、アンギラなど、モダンなフレームワーク、
全部ES6以上の機能を使って作っているし、もう前提となっているはずですね。
こういう歴史を知ると、現在のJavaScriptとかエクマスクリプトが持つ、
その中でも奇妙な仕様ですね。
イコール2つvsイコール3つのものとか、バーノスコープ、もしくはディスですね。
コンテキストに依存するディスの仕様とか動作などなど。
背景を知ると、こういう経緯があって、今こういう仕様になって落ち着いたんだっていうのも、
うなずけはするでしょうね。
まぁ受け入れたくはないというものもあると思いますけど、はい。
まぁでも少し見方が変わってくるんじゃないかなっていう感じがしました。
ではでは、ES6が登場したことで、
JavaScriptっていうのはブラウザーの補助的なスクリプト言語っていうものから、
こちらもですね、なんだかんだ本格的なアプリケーション開発言語にも大きく飛躍したんじゃないかなっていうふうに思ったりします。
とはいえ、スタートであるWebを動的なもの、かつ簡単にデザイナーでも使えるようにするみたいなお話ですけど、
これもまだ担保されていると思っていいと思います。
丁寧に書こうとしたら、ちゃんと本格的なES6の機能を使うのがいいと思いますけど、
そうではない。ブラウザーあくまで動的に動かしたいっていうだけであれば、
従来のJavaScriptで書けますし、いくらでも扱えるっていうところで、
そこも担保できてるのは良い話かなと思ってます。
はい、全世界で、おそらくですけどプログラミング言語で一番なんだかんだ今でも使われている言語は確かJavaScriptだったと記憶してますね。
というので、当時の思いとか期待っていうのがちゃんと現実になって今も続いてるよっていうのがいい話だと思って、
歴史の結びとしてはとてもいい着地の仕方なんじゃないかなと思っております。
じゃあそんなところで今回は終わっていきたいと思います。
クロージングです。
この番組面白かったよという方は是非チャンネル登録もお願いします。
もし聞いていて気になることや話してほしいトピック、感想などございましたら概要欄のフォームや
Xでハッシュタグウェブ小話でつぶやいてください。
ウェブはアルファベット、小話は漢字でもひらがなでも大丈夫です。
今回もお聞きくださりありがとうございました。
甘えどりをしながら考える技術の変遷。
次回もどうぞお楽しみに。
お相手はピースでした。
さようなら。
