autoscale: true
ECMAScript as a Living Standard
自己紹介
- Name : azu
- Twitter : @azu_re
- Website: Web scratch, JSer.info
伝えたいこと
- ECMAScriptの仕様策定は特別なプロセスではない
- そこへ参加する/見ていくのはむずかしいものではない^x
伝えたいこと
- ECMAScriptの仕様策定はただの大きな(GitHub)プロジェクト
- 普通のプロジェクトと大きな違いはない ^y
- フォーマルに物事が進む分 普通より分かりやすい
- どのように進めれば物事が進むかのパターンを学べる
ES2016 リリース :tada:
その前にES2015では何があったんだっけ?
一番大きな変化
- ES2015からは1年毎のリリースサイクルに変更される
- ES2015はその早いリリースサイクルを適応できるだけの基盤
- だからまだまだ足りない機能はある
- リリースサイクルと共に仕様策定のプロセスも変更された
- 早いサイクルと開発者/実装者からのフィードバックを得るためのプロセスへ
It’s the foundation for the next 10-20 years of JavaScript evolution -- Allen Wirfs-Brock
ECMAScript as a Living Standard
Living Standard
- ECMAScriptもLiving Standardへ
- tc39.github.io/ecma262/では常に最新の仕様が公開されている
- ES2015, 2016は1年毎のスナップショット
Living Writing :book:
ES2015以降のJavaScript入門本
github.com/asciidwango/js-primer
- ES2015以降ベースのJavaScript入門本をオープンソースで書いてる
- 仕様書はLiving Standard
- 書籍がスナップショットだけでは追いつけない
- 書籍もLivingに更新できる仕組みを作る必要がある
- 出版は予定しているが開発中の段階から公開します
for
- プログラミングをやったことがある
- 今のJavaScriptがよくわからないという人向け
- 今のJavaScriptアプリケーションを読み書きできるようなるもの
- ミーティングノートも公開している
- js-primer/meetings at master · asciidwango/js-primer
続きはGitHubで
https://github.com/asciidwango/js-primer
- 興味ある人はWatchしておいてください
- リリースだけを知りたい人は、フォームからメールアドレスを登録しておくと通知される予定です
ECMAScript 2015 - 2016 diff points
Move to GitHub
- tc39/ecma262: Status, process, and documents for ECMA262
- GitHubで仕様書、Issue、Pull Requestで開発されるようになった
WordからEcmarkupへ変更
WordからEcmarkupへ変更
- ECMAScriptの仕様を書くためのCustom Element + Ecmarkdown
- アルゴリズムのステップをMarkdown風に書ける
- これによりクロスリファレンスリンクが充実し読みやすくなった
- リンクをクリックすれば宣言元へ飛べる
Layering: Unhandled Rejection
- Unhandled Rejection Tracking Browser Events
- 実行環境が
rejectionHandled/onrejectionhandledイベントを実装できるためのHookポイントの追加
[fit] Normative: Remove [[Construct]] from generators
function * G() { construtor(){} }
new G(); // throw error
- Generatorは
newできなくなったconstructorがg.next()されるまで呼ばれないという混乱を生む挙動になっていたため- 実例とともに学ぶECMAScript 2015 〜Generator〜 – NET BIZ DIV. TECH BLOG
Normative: Add Array.prototype.includes and TypedArray.prototype.includes
- ES2015で入らなかったのは
containsがBreak the webであったため - tc39/Array.prototype.includes: Spec, tests, reference implementation, and docs for ESnext-track Array.prototype.includes
- Introducing Break the Web: Array extra methods case // Speaker Deck
Normative: Add ** exponentiation operator
- べき乗演算子
// 2の3乗算
2 ** 3 == Math.pow(2, 3);
Normative: Require Unicode 8
U+180Eがホワイトスペースではなくなった- Unicode 5.2.0では空白(Zs)の定義に
\u180Eが含まれていた
- Unicode 5.2.0では空白(Zs)の定義に
eval("1\u180E===1"); // throw exception in ES2016
// SyntaxError: illegal character in ES2016
// `true` in ES2015
Normative: Remove Proxy enumerate trap and Reflect.enumerate
Reflect.enumerateが実装上の複雑さなどの問題から削除された- Normative: Remove [[Enumerate]] and associated reflective capabilities by bterlson · Pull Request #367 · tc39/ecma262
- Why Remove Proxy [[Enumerate]] and Reflect.enumerate? | ECMAScript Daily
リリースノートはどこに?
リリースノート
- Releases · tc39/ecma262
- GitHub Releaseにリリースノートがある
- リリースノートには変更内容が書かれている
変更内容の種類
- Normative
- 新しい機能の追加、仕様の変更など
- Editorial
- 記述の修正、リファクタリング
- Layering
- ECMAScriptと連携するHTML仕様向けの機能追加、修正など
変更内容の種類はどこから?
- tc39/ecma262はコミットメッセージの規則を持っている ^1
コミットメッセージ規則の利点
- コミットメッセージの規則を持つことで検索が簡単になる
$ git clone https://github.com/tc39/ecma262.git
$ cd ecma262
$ git log --grep "Normative:" es2016-draft-1...es2016-draft-20160215
そもそも誰が仕様決めているの?
TC39
TC39とは
- ECMAScriptを策定してる専門委員会
- 言語仕様は法的な問題などに対処するため標準委員会で管理することが多い
- 重要な変更はTC39の中でConsensusを取ってから仕様へ反映
- 2ヶ月に1度のミーティングで合意を取る
Editor
- Brian Terlson @ Microsoft
- @bterlson
- ES2016〜仕様書のEditor
Need Consensus :tophat:
- 挙動を変更するものはConsensusが必要
- 既存ウェブサイトに影響を与えるものはかなり難しい
- Chrome Platform StatusやAPI usage on the web platformなど実測値が参考に使われる
- 挙動を変更しないものは、その場でPull Requestがマージされる
新しい機能 - Proposal
- 全く新しい機能も基本的には合意を得られないと追加されない
- ES2016からは機能ごとのProposalを出す
- つまり、機能ごとに仕様を決めていき毎年リリースする
- ProposalにはStage 0〜4の5段階のラベルがあり、Stage 4になったら仕様へマージされる [^2]
- こちらも2ヶ月に1度のミーティングでStageが変動する
[^2]: The TC39 Process
5段階のStage
- Strawman - アイデア
- Proposal - 提案
- Draft - ドラフト
- Candidate- 仕様書と同じ形式(実装のフィードバック期間)
- Finished - 実装が2つ、test262にテスト => 策定完了
- 次の年のECMAScript 201＊にマージされる
- Finished - 実装が2つ、test262にテスト => 策定完了
Proposalってどういうものがあるの?
Proposalの一覧
tc39/proposals: Tracking ECMAScript Proposals
Async Functions
- Stage3: 2つ目の実装が出たらStage4へ
async function gets(aURL, bURL) {
const contentA = await getURLAsync(aURL);
const contentB = await getURLAsync(bURL);
console.log(contentA, contentB);
}
Function.prototype.toString revision
Function.prototype.toString revision
- Stage 3
func.toString()が返す文字列を規定 ^3- ネイティブな関数は
[native function]を返すという事を規定
class { /* body */ }
A.toString();
/*
class { /* body */ }
*/
なぜ機能ごとの策定プロセスを取るのか?
- 1年毎にリリースするため、リリース速度をあげる目的
- できるだけ小さな単位で仕様を決めていくため
- 機能毎という小さなProposalをベースにすることで、細かくリリースできる
- 他の言語やフレームワークも似たような事をやっている
Avoid bikeshed
プログラミング言語標準化の パターンランゲージ [^4] -- Allen Wirfs-Brock(ES2015 Editor)
[^4]: :memo: プログラミング言語標準化のパターン
"maximally minimal"
- 言語デザインは複雑になるほどConsensusを取るのが難しくなる
- "maximally minimal"とは反対意見がある原因やそう思える部分を最大限取り除いた最小のものを仕様にするという手法
"maximally minimal" classes
- ES6での
classの事例 - strawman\:maximally_minimal_classes [ES Wiki]
- 全体として必要という合意があるにもかかわらず、詳細の同意が得られず進まない問題へのパターン
- 全体として合意できる最大限最小のものをES6 Classesとした
- 類似: Less is more
なぜ策定プロセスが公開されているのか?
プロセスの透明性
- tc39/tc39-notesにミーティングノートが公開されている
- どのような議論が行われ、どのような意思決定がされたのか
- なぜ、このProposalは必要なのか
- なぜ、このProposalはStage Xなのか
- なぜ、このProposalは廃止されたのか
一般のライブラリでも同じ
- React: React Core Meeting Notes
- Ember.js: Meeting minutes from the Ember.js core teams
- Node.js: Technical Steering Committee meeting
- jQuery: jQuery Core Team | jQuery Meetings
^ 今書いてるJavaScriptの本もミーティングノートを公開しています。
開発者がプロセスに参加する
- (広い意味での)開発者にとって公開されたプロセスは有益
- ECMAScriptはStage 3で2つのブラウザへの実装が必要
- ブラウザはフラグ付きで実装できる
- 開発者はフラグをオンにして試せる
- Babelのようなツールでもっと前に試せる
ブラウザとフラグ
- 全てのブラウザはフラグ管理して実装する
- WebKitもprefixではなくフラグで管理する宣言をした
- β/Nightly版を使えば簡単に利用できる
フィードバック
- 仕様があっても実装されなければ意味がない
- 実装されても使われなければ意味がない
- 使う側もプロセスの理解とフィードバックが重要
- フィードバックをまともに得ずに進んだものは壊れた歴史
フィードバックの方法
- 仕様なら
- ProposalリポジトリへIssueを立てる
- ES Discussに投げる
- 実装なら
- 各ブラウザ/実装のIssueへ
- 何がわからないのかわからないなら
どこから情報を得るか
情報源
- リリースノート
- ミーティングノート
- ロードマップ/Proposal
情報源
- Issue
- Issues · tc39/ecma262 and Proposal's issue
- メーリングリスト/質問
- テスト
- 実装
- 各ブラウザ、anba/es6draft
ECMAScript Daily
- ECMAScriptについてニュースサイト
- JSer.infoのECMAScript版
情報源を見てみると
- GitHubにリポジトリがあって、IssueやPull Requestでやり取りしていて、リリースノートがGitHub Releaseにあって、議論の結果が残っていて、未確定なロードマップみたいなものがあって、実装やテストがある
- 各実装がGitHubの該当Issueへリンクを貼りクロスリファレンスになっている
- 普通のGitHubプロジェクトと大差ないのでは :question:
ECMAScriptを大きな
GitHubプロジェクトとして見る
ECMAScriptがやっていること
- :heavy_check_mark: 更新内容は普段からコミットの段階で整理しておく
- コミットメッセージの規約を設けるなどして、整理しておく
- :memo: リリースノートはGitHub Releaseで公開している
- リリースノートはアクセスしやすい/更新が分かりやすい場所へ
ECMAScriptがやっていること
- :thought_balloon: 複雑な設計問題に対してはパターンを使う
- "maximally minimal"は意思決定のデットロックを壊すツール
- :tophat: Consensusが必要なものはミーティングで意思決定をする
- 慎重な意思決定が必要な部分は時間を取ってミーティングを行う
- :pencil2: ミーティングの内容は透明性のために公開している
- 話し合った過程や内容を公開することで、部外者の"なぜ?"を解決できるようにする
ECMAScriptがやっていること
- :pushpin: ProposalにはStage Xというラベリングをしている
- Proposalの現在のステータスが分かるようにラベリングしている
- :clock12: Stage 3では開発者からフィードバックを得る方法/期間を提供している
- 仕様確定前に十分なフィードバックを得る方法や期間を開発者に提供する
6行まとめ
- :heavy_check_mark: 更新内容は普段からコミットの段階で整理しておく
- :memo: リリースノートはGitHub Releaseで公開している
- :thought_balloon: 複雑な設計問題に対してはパターンを使う
- :tophat: 慎重な意思決定が必要な部分は時間を取ってミーティングを行う
- :pencil2: ミーティングの内容は透明性のために公開している
- :pushpin: Proposalの現在のステータスが分かるようにラベリングしている
- :clock12: 仕様として確定する前に開発者からフィードバックを得る方法/期間を提供している
1行まとめ
大きなGitHubプロジェクトとそんなに変わらない
おわり
参考
- V8 JavaScript Engine: ES6, ES7, and beyond
- Previewing ES6 Modules and more from ES2015, ES2016 and beyond | Microsoft Edge Dev Blog
- azu/browser-javascript-resource: Browser JavaScript Resource.
- ECMAScript 6 compatibility table
- APIデザインの極意 Java/NetBeansアーキテクト探究ノート - インプレスブックス