title | author | layout | date | category | tags | |||
---|---|---|---|---|---|---|---|---|
ECMAScriptカンニングペーパー |
azu |
post |
2015-10-18T00:00 |
JavaScript |
|
ECMAScript関係についてざっとみるカンニングペーパー
2015年10月18日の次世代 Web カンファレンスでstandardizationのセッションで議論に参加するらしいのでそれのカンペです。
ここに書かれている情報は2015年10月17日現在のものです。
Ecma Internationalによって標準化されてるJavaScriptの仕様の事
- 仕様: ECMAScript
- 実装: JavaScript
2015年9月25日の最新版はECMAScript 2015(aka. ES6)
ECMAScriptの事。_262_はEcma Internationalでの管理番号。
Technical Committee = 専門委員会。
TC39: ECMAScriptを策定してる専門委員会 Ecmaは色々な仕様を策定しているので、その中でECMAScriptを策定してるグループの名前がTC39。
ちなみに同じくEcma標準化されてるDartはTC52。
一応の正式名称はECMAScript 2015。 通称(多くの人に馴染みがあるという意味)ではES6と呼ぶ人も多い。
ES2015が正式名称であり、来年以降のECMAScriptの策定やリリースのスタイルに名称を合わせるというのが理由
ES6以降は1年毎にリリースしていく予定のため、2015, 2016...となるように変更された。
ES6の仕様策定のリーダー(実際に仕様書に載せる文章を書く人)
- Allen Wirfs-Brock(アレン・ワーフスブラック) @
Mozillafamily business - @awbjs
ECMAScriptはデファクト標準(Ecma Internationalにより標準化)でもあり、ISO/IEC 16262としてISO標準化(デジュール標準)もされている
- OSSコミュニティの“中の人”(4):できないことは全部やる。できる依頼は断る――竹迫良範氏インタビュー【後編】 (1/2) - @IT
- Devsumi2010 Ecmascript5 (ISO/IEC JTC1/SC22)
日本ではISO/IEC JTC1/SC22のECMAScript adhoc委員会でFast Trackの手続きをやってる。(@azuもレビュアとして参加)
AWB: The issue is ISO. There is concern about divergence between those two documents (ISO document with changes made by their reviewers, Ecma version)
BT/IS clarifying why we need ISO version?
ECMAScript 7 or 2016って何のこと??
大抵の場合は次(ES6の次)のECMASCriptの事を言ってる。
「ES7のDecoratorについて」といった言い方はまだ仕様に入ることすら決まっていないもののことを言っているので正しくはない。
「次期ECMAScriptに提案されているDecoratorについて」というのがより正確。
次期ECMAScriptの事をECMAScript nextとかES.nextと言ったりもする。
現在から見て次期ECMAScriptの事 (2015年9月25日から見ると、次期ECMAScriptは2016以降の事)
- Brian Terlson(ブライアン・テルソン) @ Microsoft
- @bterlson
Thanks TC39 for the support :) I'm excited to take on the editorship of ECMA262! -- https://twitter.com/bterlson/status/626104816511512576
2015年7月29日のTC39ミーティングで承認され、ECMAScriptのエディタはAllen Wirfs-BrockからBrian Terlsonに交代。
ES.nextの仕様策定はBrian Terlsonの元に行われる。
ES.nextは今までのECMAScriptとは策定プロセスが異なる。
ECMAScript 2016からは機能ごとに仕様のプロポーザル(提案)を出し策定していく。 それぞれのプロポーザルにはStageと呼ばれる5段階のラベルが振られている。
Stage4となったプロポーザルは次期ECMAScriptに取り込まれ、正式にECMAScriptの仕様となる。
-
- Stawman
-
- Proposal
-
- Draft
-
- Candidate
-
- Finished
言いかたを変えると、次期ECMAScriptは1年ごとに出るので、その時までにStage4となったものが次期ECMAScriptに入る。
<iframe src="http://azu.github.io/tc39-svg/" ></iframe>via What’s New in JavaScript for Fast and Scalable Apps | Build 2015 | Channel 9
それぞれのStageについて。 詳しくはThe TC39 Processを読む
- Stage 0: Stawman
- アイデア
- Stage 1: Proposal
- プロポーサルの目的や解決方法を示す
- Polyfillやデモ等を用いて解説する
- Stage 2: Draft
- いわゆるドラフト
- ECMAScript標準と同じルールでAPIや構文、セマンティックについて説明していなければならない
- Stage 3: Candidate
- 仕様は完成した状態
- 実装や外部のフィードバックを求める状態
- レビュアはその仕様策定者以外ならだれでもなれるが専門的な知識を持っている必要がある
- ECMAScriptのエディタがチェックする必要があり
- Stage 4: Finished
- 2つの実装(not polyfill)が必要
- ECMAScriptへ取り込まれる準備が完了したことを示す状態
- ECMAScriptのエディタがチェックする必要があり
それぞれのstageはTC39のミーティング等で話し合い、それぞれのstageの条件を満たしている場合に次のstageへあがる。
色々な人
- ブラウザベンダー
- ウェブ開発者
tc39/ecma262にプロポーザル一覧とStageが載っている。
tc39/ecma262のstage0.md
にプロポーザルを追加してPull Requestする。
Ecma Internationalの特許、著作権のポリシーに同意してる人ならば誰でも出来る。
ECMAScriptに仕様提案までのフロー(Ecma非会員の場合)
1. 仕様策定のプロセスを理解しましょう
2. フォームから必要な情報送ってルールに同意してね
3. ProposalをPull Requestしましょう
https://t.co/vTcqEPzzBg
— azu (@azu_re) October 9, 2015
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
ECMAScript 2016のドラフトはGitHubで公開されている
- メーリングリスト
- TC39のFace to Faceのミーティング
- 各仕様のGitHub Issue
- ECMAScriptのBugzilla
- SNS
- Twitter/GitHub/Google+
ES2016 Draft 1がリリースされている。
Draft 1は基本的にはES2015と同じで、細かいバグ修正のみ。 その他の違いとしては、仕様書がWordではなくEcmarkupで書きなおされたこと。
リリースする時期は決まっていて、General Assemblyで承認されて初めてリリースされるので、次の総会が行われる2016年6月15-16日あたりにES2016がリリースされる。
仕様を提出するまでにStage 4となったものも一緒にES2016に含まれてリリースされるが、ES2016はProposalが独立してるのでそれを仕様にマージしたり編集の作業が必要(Brianさんが頑張る)
そのため、提出の半年ぐらい前には入れる機能はフリーズされる(何を入れるかを決めて、残りはtypoや実装からのフィードバックなどの機能以外の修正)。
なので、ES2016は2016年1月ぐらいには細かいところを除きフリーズされる(この時期を"freezing" deadlineと呼んだりしてる)
結論: 2016年1月中にStage 4となってる仕様がES2016には入る。
可能性としてありえるのは以下の仕様あたり
2016年1月までにあるミーティングは2回。
- November 17 - 19, 2015 (San Jose - Paypal)
- January 26 - 28, 2016 (San Francisco - Salesforce)
例) ES6の場合
ES6は2015年の6月17日にリリースされた。
以下の図のように大体1月ぐらいには機能はフリーズされて、そこからは実装のフィードバックを受けての修正がメインとなっていた(実際には細かな機能が増えたりしたけど。。)
今までのECMAScriptはWordファイルだったが、ES.nextではEcmarkupを使ったHTMLベースで書くようになっている。
<emu-production name="SourceCharacter" type="lexical" id="prod-SourceCharacter">
<emu-nt><a href="#prod-SourceCharacter">SourceCharacter</a><emu-mods></emu-mods></emu-nt><emu-geq>::</emu-geq><emu-rhs><emu-gprose>any Unicode code point</emu-gprose></emu-rhs>
</emu-production>
Ecmarkupは仕様書向けのタグを定義したHTML。
tc39/ecma262にそれぞれのプロポーザルのstageが掲載されている。 またstageは2ヶ月に一度行われるTC39のミーティングにより変化するため、ミーティングの記録されている。
ECMAScript 2016のリリース予定は2016年の6月15-16日
EcmaのGeneral Assembly(GA)の総会で正式に承認された後にリリースされるので、次にGAの総会が行われるのは15-16 Juneなので。
Module loaderはES6から外されたけど、whatwg/loaderで議論されてる。
仕様として提案されたが、ES6には入らなかったものも多い。
仕様そのものが良くない、仕様策定に時間がかかる(Module loaderはコレ)など理由は色々。
ES.nextの仕様に入るには2つ以上の実装が必要。 ここに関わるのはブラウザベンダーによる実装。
- Chakra @ MicroSoft
- SpiderMonkey @ Mozilla
- V8 @ Google
- JavaScriptCore @ Apple
組み込みやJVM向けなどもあるけど多分カウントされない気がする。
ECMAScript 6 compatibility tableで、ブラウザの実装状況が見ることが出来ます。
それぞれのブラウザの更新履歴などについては以下を参照。
TranspilerはSource-to-source compilerの事。 コードからコードへ変換するツールの事で、JavaScriptやCSSなどの世界では色々なツールがある。
ECMAScriptではES6以降のコードをES5のコードに変換するBabel(元々は6to5という名前)や、 CSSではPostCSSなどがある。
古い環境にそもそも同等の表現を出来る機能がない場合はTranspilerでも実装する事はできない。
例) ES6 Proxy、ES6 Classesのサブクラスなど
同様の事が原因で、全ての機能が仕様通りの動きをするわけではない。
Babelの作者である@sebmckもTranspilerだけで新しい言語機能を学ぶべきではないと言っている。
一種のライブラリ。
仕様で策定されている機能だが、古いブラウザなどではまだ実装されていない時に、APIが全く同じ互換実装を提供するライブラリの事。
Promise
やArray.from
などのオブジェクトやメソッドの追加が主な働き。
Transpilerと違って新しい構文を古いブラウザで動かせるようにするのではなく、既存の構文で新しい機能を追加する(つまりライブラリ)
ECMAScriptにはマクロのような仕組みはないのでコードで構文を拡張することが難しい。 そのため、TranspilerとPolyfillを使い分け、組み合わせて利用する。
BabelはTranspiler、core-jsはPolyfill。
ECMAScriptよりもDOM APIはpolyfillとして実装しやすいため多くのPolyfillが実装されている。
BabelではES6で追加された構文の大部分が変換でき、古いブラウザなどでもES6を利用できるようになっている。
そのため、とりあえずBabelを使っておけばいう人も多い。
ブラウザ側の実装も進んでいるため、IEのようなアップデートのライフサイクルが異なるブラウザを無視すれば、モダンなブラウザでもES6の機能を利用できるようになってきている。
Q. ブラウザでも実装された後もBabelの使い続けていくのか?それは健全なのか?という話について。
A. 個人的な考えではYES。
Babelを利用するのは利用者のブラウザで動かせるという実利的な理由もあるが、仕様策定側から見てもメリットがあると考えられている。
TC39のメンバーでもある@jhusainが、「これからもTranspilerをずっと使い続けていくのか?」という疑問に対して次のように答えている。
“I hope so. Transpilers have been an incredibly valuable thing for the committee.”
- 168JSJ The Future of JavaScript with Jafar Husain
- JSJ The Future of JavaScript with Jafar Husainのメモ 📝
現実的な問題として仕様に関わる人があまり数が多くない。 しかし、仕様策定側は仕様に対するフィードバックを求めている。
Transpilerがあると、策定中の仕様をウェブ開発者が試すことができ仕様に対するフィードバックがより多く集まる事が挙げられている。
ウェブの変化が高速になっているのに伴い、ECMAScriptなどの仕様策定も高速になっていく傾向がある。
- ES.nextは1年ごとのリリース。機能ベースの仕様策定
- HTML5仕様のモジュール化
そのため、できるだけ短い期間で多くのフィードバックが必要になる傾向があり、フィードバックする機会を失う問題が起きやすいので、Transpilerはそこを補完する事ができるのではと期待されている。
フィードバック側は最新の情報に気づかないとフィードバックする機会を失う
ES.nextでも Stage 1: Proposal あたりで、TranspilerやPolyfillを仕様と共に提供して、より多くの人が試せるようにしているケースが多い。(TranspilerやPolyfillはStage 4となるのに必要な実装数にはカウントされない)
やはり、仕様の問題は実装時に多く見つかるので、JavaScriptエンジンに仕様の実装をしてみる。 JavaScriptエンジンの多くはJavaScriptでJavaScriptを実装できるようになっているので、機能によっては外部の人でも手を出しやすいとの事。
仕様の問題を見つけたらES Discuss等に投げて、bugs.ecmascript.orgにIssueを立てるなど。
ブラウザの実装を試して、挙動が異なってたりするならブラウザベンダーのBTSにIssueを立てるなど。
- ES.nextの仕様は殆どがGitHubのリポジトリを持ってるので、それぞれのリポジトリにIssueやPull Requestを送ってみる。
- ECMAScriptの仕様本体もtc39/ecma262にある
- CONTRIBUTING.mdを見て分かるように普通にIssueやPull Requestで修正できる
- 細かい変更ならCLAへのサインも必要ない
- 最新の議論はTC39 Meeting Notesに記録されているがtypoなどの間違いが多いので修正してみる
- Transpilerなどのツールが新しい構文に対応するには、まずそのコードをパースできないといけない。
- 各種パーサが対応出来るようにPull Requestを送ってみる
- [2015-02] 最近のJavaScript AST標準化の動き | Web Scratch
- 仕様のTranspilerやPolyfillを実装してみる
- TranspilerやPolyfillを使ってみて使い勝手などのフィードバックを書いてみる
検索しましょう!