コラム: ECMAScript/JavaScript策定プロセス

[azu]

コラム的な扱い

2016-05-27のES2016以降を含めるかどうか?でも議論したけど、策定プロセスやどこで誰が決めているのかという事について触れる。

目的

JavaScriptでは先行実装的を取り入れたという形のツールやライブラリが多い。
ECMAScriptのProposalsは、必ず仕様に入るわけではないので、あくまでそれは提案中の仕様にすぎないという話は現実的に知っておいたほうが良い。(変に振り回されても困るため)
そのため、その判断基準を身につけるという意味での話が必要となる。

仕様以外のはなしとしてもopinionが強いものが結構多い(これは単に人数が多いというのもある)ので、そういう情報の読み方探し方という話になってしまうのかもしれない。

[azu]

http://refactoringjs.com/ で初めてプロセスの説明を書籍で見た

[azu]

Typescript never had syntactic breaking changes. Meaning valid syntax that is supported by one version and disallowed by a newer version. All breaking changes are semantic in nature; either new error checks or new behaviors for the type system. All these are outside the scope of Babylon. There are some changes in the resulting code from tsc but these are not relevant here either.
babel/babylon#523 (comment)

構文的な変更はしないけど、意味論的な変更はするという話。
ECMAScriptでも同じような気がするけど、Allenさんとかが言ってたわけではなかったけ?

ECMAScriptでは一度入った変更は基本的に取り除くのが難しいから、こういったプロセスがあるという話がこのコラムの主軸だと思う。
(取り除く例外ケースは、SharedArrayBufferみたいなセキュリティ的な理由やGoogleのデータやHTTP Archiveを使って殆ど使われてないときなど)

一方で実装も早く進める必要があるから、仕様策定のプロセスに実装が2つ必要という点は結構特殊にも思える。

プログラミング言語標準化のパターンとかmaximally minimalの話とかもここなんだろなー