ECMAScriptのカンペ

ECMAScript関係についてざっとみるカンニングペーパー。

2015年10月18日の次世代 Web カンファレンスでstandardizationのセッションで議論に参加するらしいのでそれのカンペです。

ここに書かれている情報は2015年10月17日現在のものです。

追記: 縦に長い記事読むのが面倒な人向けにスライド形式にしたものも置いておきます。

ECMAScriptとは?

Ecma Internationalによって標準化されてるJavaScriptの仕様の事。

  • 仕様: ECMAScript
  • 実装: JavaScript

2015年10月18日のStableな最新版はECMAScript 2015(aka. ES6)。

ECMA-262

ECMAScriptの事。_262_はEcma Internationalでの管理番号。

TC39

Technical Committee = 専門委員会。

TC39: ECMAScriptを策定してる専門委員会のこと。

Ecmaは色々な仕様を策定しているので、その中でECMAScriptを策定してるグループの名前がTC39。

ちなみに同じくEcma標準化されてるDartはTC52。

ECMAScript 6 / 2015の呼び方

一応の正式名称はECMAScript 2015。通称(多くの人に馴染みがあるという意味)ではES6と呼ぶ人も多い。

ES2015が正式名称であり、来年以降のECMAScriptの策定やリリースのスタイルに名称を合わせるというのが理由

ES6以降は1年毎にリリースしていく予定のため、2015, 2016…となるように変更された。

ES6のエディタリーダー

ES6の仕様策定のリーダー(実際に仕様書に載せる文章を書く人)。

icon

Ecma標準とISO標準の違い

ECMAScriptはデファクト標準(Ecma Internationalにより標準化)でもあり、ISO/IEC 16262としてISO標準化(デジュール標準)もされている。

日本ではISO/IEC JTC1/SC22のECMAScript adhoc委員会でFast Trackの手続きをやってたり(@azuもレビュアとして参加)。

なぜISO標準が必要?

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 ? 2016

ECMAScript 7 or 2016って何のこと??

大抵の場合は次(ES6の次)のECMAScriptの事を言ってる。

「ES7のDecoratorについて」といった言い方はまだ仕様に入ることすら決まっていないもののことを言っているので正しくはない。

「次期ECMAScriptに提案されているDecoratorについて」というのがより正確。

次期ECMAScriptの事をECMAScript nextとかES.nextと言ったりもする。

ES.next

現在から見て次期ECMAScriptの事(2015年10月18日から見ると、次期ECMAScriptは2016以降の事)。

ES.nextのエディタリーダー

Brian Terlson

  • 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と策定プロセス

ES.nextは今までのECMAScriptとは策定プロセスが異なる。

ECMAScript 2016からは機能ごとに仕様のプロポーザル(提案)を出し策定していく。それぞれのプロポーザルにはStageと呼ばれる5段階のラベルが振られている。

Stage 4となったプロポーザルは次期ECMAScriptに取り込まれ、正式にECMAScriptの仕様となる。

    1. Strawman
    1. Proposal
    1. Draft
    1. Candidate
    1. Finished

言いかたを変えると、次期ECMAScriptは1年ごとに出るので、その時までにStage 4となったものが次期ECMAScriptに入る。

ecmascript-timeline

via What’s New in JavaScript for Fast and Scalable Apps | Build 2015 | Channel 9

TC39 Process: Stage

それぞれのStageについて。詳しくはThe TC39 Processを読む。

  • Stage 0: Strawman
    • アイデア
  • 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へあがる。

何で1年ごとにリリースするの?

ES6はリリースするまで結局6年かかったので、もっと少しずつ出していきたいため。

この方針はエディタリーダーが交代する前から決まっていた。

誰がプロポーザル書いてるの?

色々な人。

  • ブラウザベンダー
  • ウェブ開発者

tc39/proposalsにプロポーザル一覧とStageが載っている。

新しいプロポーザルを提案するには

tc39/proposalsのstage0.mdにプロポーザルを追加してPull Requestする。Ecma Internationalの特許、著作権のポリシーに同意してる人ならば誰でも出来るが、基本的にはTC39で議論してからPull Requestする。

決まったパターンがあるわけではなく最終的にPull Requestでマージされるというのが決まっているだけ。

よくある流れとしては

  1. ES Discuss(ML)で議論
  2. 2ヶ月に1回のTC39ミーティングで議題に取り上げる
  3. TC39でそのプロポーザルをStage 0でOKと承認する(たまにStage 1からとかもある)
  4. tc39/ecma262のstage0.mdにPull Request
  5. マージ

ECMAScriptとGitHub

ECMAScript 2016のドラフトはGitHubで公開されている。

仕様についてはどこで議論されてるの

結局ECMAScript 2016って何が入るの?

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-02-12): 実際に入るものが決まった => ECMAScript 2016 features & changes - JSer.info

2016年1月までにあるミーティングは2回。

  • November 17 - 19, 2015 (San Jose - Paypal)
  • January 26 - 28, 2016 (San Francisco - Salesforce)

例) ES6の場合

ES6は2015年の6月17日にリリースされた。

以下の図のように大体1月ぐらいには機能はフリーズされて、そこからは実装のフィードバックを受けての修正がメインとなっていた(実際には細かな機能が増えたりしたけど)。

ES6 Release Schedule

＊画像横に長いのでクリック

Ecmarkup

今までの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。

ES.nextの進捗

tc39/proposalsにそれぞれのプロポーザルのStageが掲載されている。またStageは2ヶ月に一度行われるTC39のミーティングにより変化するため、ミーティングの記録を読めばいい。

次の仕様っていつリリースされるの?

ECMAScript 2016のリリース予定は2016年の6月15-16日。

EcmaのGeneral Assembly(GA)で正式に承認された後にリリースされるので、次にGAが行われるのは15-16 Juneなので。

ECMAScriptとModuleとWHATWG

Module loaderはES6から外されたけど、whatwg/loaderで議論されてる。

ES6に入らなかったプロポーザルって?

仕様として提案されたが、ES6には入らなかったものも多い。

仕様そのものが良くない、仕様策定に時間がかかる(Module loaderはコレ)など理由は色々。

ECMAScriptの実装ってどれぐらいあるの?

ES.nextの仕様に入るには2つ以上の実装が必要。ここに関わるのはブラウザベンダーによる実装。

組み込みやJVM向けなどもあるけど多分カウントされない気がする。

ECMAScriptの実装状況ってどうなの?

ECMAScript 6 compatibility tableで、ブラウザの実装状況を見ることが出来ます。

それぞれのブラウザの更新履歴などについては以下を参照。

Transpilerって何?

TranspilerはSource-to-source compilerの事。コードからコードへ変換するツールの事で、JavaScriptやCSSなどの世界では色々なツールがある。

ECMAScriptではES6以降のコードをES5のコードに変換するBabel(元々は6to5という名前)や、CSSではPostCSSなどがある。

古い環境にそもそも同等の表現を出来る機能がない場合はTranspilerでも実装する事はできない。

例) ES6 Proxy、ES6 Classesのサブクラスなど

同様の事が原因で、全ての機能が仕様通りの動きをするわけではない。

Babelの作者である@sebmckもTranspilerだけで新しい言語機能を学ぶべきではないと言っている。

slide

Polyfillって何?

一種のライブラリ。

仕様で策定されている機能だが、古いブラウザなどではまだ実装されていない時に、APIが全く同じ互換実装を提供するライブラリの事。

PromiseやArray.fromなどのオブジェクトやメソッドの追加が主な働き。Transpilerと違って新しい構文を古いブラウザで動かせるようにするのではなく、既存の構文で新しい機能を追加する(つまりライブラリ)。

ECMAScriptにはマクロのような仕組みはないのでコードで構文を拡張することが難しい。そのため、TranspilerとPolyfillを使い分け、組み合わせて利用する。

BabelはTranspiler、core-jsはPolyfill。

ECMAScriptよりもDOM APIはPolyfillとして実装しやすいため多くのPolyfillが実装されている。

ずっとBabelを使い続けるのか?

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.”

現実的な問題として仕様に関わる人があまり数が多くない。しかし、仕様策定側は仕様に対するフィードバックを求めている。

Transpilerがあると、策定中の仕様をウェブ開発者が試すことができ仕様に対するフィードバックがより多く集まる事が挙げられている。

ウェブの変化が高速になっているのに伴い、ECMAScriptなどの仕様策定も高速になっていく傾向がある。

そのため、できるだけ短い期間で多くのフィードバックが必要になる傾向があり、フィードバックする機会を失う問題が起きやすいので、Transpilerはそこを補完する事ができるのではと期待されている。

フィードバック側は最新の情報に気づかないとフィードバックする機会を失う

ES.nextでも Stage 1: Proposal あたりで、TranspilerやPolyfillを仕様と共に提供して、より多くの人が試せるようにしているケースが多い(TranspilerやPolyfillはStage 4となるのに必要な実装数にはカウントされない)。

ES6で言語としてのベースラインがかなり整ったので、普通に使うだけならES6の機能だけでも十分に使える。 なので、新しい仕様をわざわざ試したくない場合は別にBabelを使わなくなるというのはあり得る。

どうやって仕様へContributingするの?

ES6

やはり、仕様の問題は実装時に多く見つかるので、JavaScriptエンジンに仕様の実装をしてみる。JavaScriptエンジンの多くはJavaScriptでJavaScriptを実装できるようになっているので、機能によっては外部の人でも手を出しやすいとの事。

仕様の問題を見つけたらES Discuss等に投げて、bugs.ecmascript.orgにIssueを立てるなど。

ブラウザの実装を試して、挙動が異なってたりするならブラウザベンダーのBTSにIssueを立てるなど。

ES.next

  • ES.nextのプロポーザルはマージされる(Stage 4となる)まで、GitHubのリポジトリを持っている。
  • それぞれのリポジトリにIssueやPull Requestを送ってみる
  • ECMAScriptの仕様本体もtc39/ecma262にある
    • CONTRIBUTING.mdを見て分かるように普通にIssueやPull Requestで修正できる
    • 細かい変更ならCLAへのサインも必要ない
  • 最新の議論はTC39 Meeting Notesに記録されているがtypoなどの間違いが多いので修正してみる
  • Transpilerなどのツールが新しい構文に対応するには、まずそのコードをパースできないといけない
  • 仕様のTranspilerやPolyfillを実装してみる
  • TranspilerやPolyfillを使ってみて使い勝手などのフィードバックを書いてみる

こんな機能ってES.nextに入るの?

検索しましょう！

続きはウェブで