この章では、ECMAScript 6 に関するよくある質問に答えます。
ES6 のほとんどは現在のエンジンで既にサポートされています。どこで何がサポートされているかについては、Kangax の ES6 互換性テーブルを参照してください。
その他のオプション（たとえば、インタラクティブな ES6 コマンドラインや Babel を介した ES6 から ES5 へのトランスパイル）については、「Setting up ES6」の「ECMAScript 6 のデプロイ」の章を参照してください。
はい、いいえ。正式名称は ECMAScript 2015 ですが、ES6 は誰もが知っていて使用している名前です。そのため、この本では後者を使用することにしました。
ES6 以降、ECMAScript のエディションは、新しいプロセスと毎年のリリースサイクルで作成されます。これは、新しい命名スキームに切り替える良い機会であるように思えます。したがって、ES6 の次のエディションには「ECMAScript 2016」という名前を使用します。
何もする必要はありません。ECMAScript 6 は ECMAScript 5 のスーパーセットです。したがって、すべての ES5 コードは自動的に ES6 コードになります。これは、この新しいバージョンを段階的に採用するのに非常に役立ちます。ES6 が完全に下位互換性を維持する方法の詳細は、「ワン JavaScript」の章で説明されています。
ES6 はどこでもますますサポートされるようになっています。それは、もう ECMAScript 5 を学ぶべきではないということでしょうか？いくつかの理由からそうではありません。
ES6 が肥大化しており、役に立たない *糖衣構文*（すでに存在するもののより便利な構文）を導入しているという非難が時々見られます。
ただし、多くの点で、JavaScript はようやく Python や Ruby などの言語に追いついています。どちらも依然として多くの機能を持ち、はるかに豊富な標準ライブラリが付属しています。
ES6 が大きすぎると不満を言う人がいたら、しばらく試してみることをお勧めします。誰も新しい機能の使用を強制しません。「コア ES6 機能」の章を参照して、まず小さなことから始めて、ES6 に慣れてきたら、さらに新しい機能を使用できます。これまでのところ、実際に ES6 を使用してプログラミングした（それについて読んだのではなく）人々からのフィードバックは、圧倒的に好意的です。
さらに、表面的には糖衣構文（クラスやモジュールなど）のように見えるものは、言語に必要な標準化をもたらし、将来の機能の基盤として機能します。
最後に、いくつかの機能は通常のプログラマーではなく、ライブラリ作成者向けに作成されました（例：ジェネレータ、イテレータ、プロキシ）。「通常のプログラマー」は、それらを少し知っているか、まったく知る必要はありません。
確かに、ECMAScript 仕様は大幅に拡張されました。ECMAScript 5.1 PDF は 245 ページでしたが、ES6 PDF は 593 ページです。ただし、比較として、Java 8 言語仕様は（インデックスを除いて）724 ページです。さらに、ES6 仕様には、他の多くの言語仕様が実装定義として省略している詳細が含まれています。また、標準ライブラリの仕組みも規定しています2。
当初、ES6 には（Haskell や Python と同様に）配列とジェネレータの内包表記を含める予定でした。しかし、TC39 が 2 つの道を探求したかったため、追加されませんでした。
静的型付けは ES6 の一部ではありません。ただし、次の 2 つのテクノロジーにより、JavaScript に静的型付けが追加されます。同様の機能は、最終的に標準化される可能性があります。
静的型付けの 2 つの利点
TypeScript と Flow はどちらも同じ表記法を使用しています。型アノテーションはオプションであるため、このアプローチは比較的軽量になります。アノテーションがなくても、型はしばしば推論できます。したがって、この種の型チェックは、完全にアノテーションのないコードであっても、整合性チェックとして役立ちます。