Dieses Kapitel beantwortet einige häufig gestellte Fragen zu ECMAScript 6.
Die meisten Features von ES6 werden bereits in aktuellen Engines unterstützt. Konsultieren Sie die Kangax' ES6-Kompatibilitätstabelle, um herauszufinden, was wo unterstützt wird.
Weitere Optionen (z. B. interaktive ES6-Kommandozeilen und das Transpilieren von ES6 zu ES5 über Babel) finden Sie in Kap. „Deploying ECMAScript 6“ in „Setting up ES6“.
Ja und nein. Der offizielle Name ist ECMAScript 2015, aber ES6 ist der Name, den jeder kennt und verwendet. Deshalb habe ich mich entschieden, letzteren für dieses Buch zu verwenden.
Nach ES6 werden ECMAScript-Editionen über einen neuen Prozess und einen jährlichen Release-Zyklus erstellt. Das scheint eine gute Gelegenheit zu sein, zum neuen Namensschema zu wechseln. Daher werde ich den Namen „ECMAScript 2016“ für die Edition nach ES6 verwenden.
Es gibt nichts zu tun: ECMAScript 6 ist eine Obermenge von ECMAScript 5. Daher ist Ihr gesamter ES5-Code automatisch ES6-Code. Das hilft enorm bei der schrittweisen Übernahme dieser neuen Version. Wie genau ES6 vollständig abwärtskompatibel bleibt, wird in dem Kapitel über „One JavaScript“ erklärt.
ES6 wird überall zunehmend gut unterstützt. Bedeutet das, dass Sie ECMAScript 5 nicht mehr lernen sollten? Das tut es aus mehreren Gründen nicht.
Gelegentlich stößt man auf Vorwürfe, ES6 sei aufgebläht und führe zu viel nutzlosen *syntactic sugar* (bequemere Syntax für etwas, das bereits existiert) ein.
JavaScript holt jedoch in vielerlei Hinsicht nur mit Sprachen wie Python und Ruby auf. Beide haben immer noch mehr Features und eine weitaus reichhaltigere Standardbibliothek.
Wenn sich jemand über die Größe von ES6 beschwert, schlage ich vor, es eine Weile auszuprobieren. Niemand zwingt Sie, eines der neuen Features zu verwenden. Sie können klein anfangen (siehe Kap. „Core ES6 features“ für Vorschläge) und dann mehr neue Features nutzen, wenn Sie sich mit ES6 wohler fühlen. Bisher sind die Rückmeldungen, die ich von Leuten erhalte, die tatsächlich mit ES6 programmiert haben (im Gegensatz zum Lesen darüber), überwältigend positiv.
Darüber hinaus bringen Dinge, die oberflächlich wie syntactic sugar aussehen (wie Klassen und Module), dringend benötigte Standardisierung in die Sprache und dienen als Grundlage für zukünftige Features.
Schließlich wurden mehrere Features nicht für normale Programmierer, sondern für Bibliotheksautoren entwickelt (z. B. Generatoren, Iteratoren, Proxys). „Normale Programmierer“ müssen sie nur oberflächlich oder gar nicht kennen.
Die ECMAScript-Spezifikation ist tatsächlich enorm gewachsen: Das ECMAScript 5.1 PDF hatte 245 Seiten, das ES6 PDF hat 593 Seiten. Aber zum Vergleich: Die Java 8 Language Specification hat 724 Seiten (ohne Index). Darüber hinaus enthält die ES6-Spezifikation Details, die viele andere Sprachspezifikationen als implementierungsabhängig weglassen. Sie gibt auch an, wie ihre Standardbibliothek funktioniert2.
Ursprünglich sollte ES6 Array- und Generator-Comprehensions (ähnlich wie in Haskell und Python) enthalten. Sie wurden jedoch nicht hinzugefügt, da TC39 zwei Wege erkunden wollte:
Statische Typisierung ist kein Teil von ES6. Die folgenden beiden Technologien fügen JavaScript jedoch statische Typisierung hinzu. Ähnliche Funktionen könnten schließlich standardisiert werden.
Zwei Vorteile der statischen Typisierung sind:
Sowohl TypeScript als auch Flow verwenden dieselbe Notation. Typannotationen sind optional, was diesen Ansatz relativ leichtgewichtig macht. Selbst ohne Annotationen können Typen oft abgeleitet werden. Daher ist diese Art der Typüberprüfung auch für vollständig unannotierten Code nützlich, als Konsistenzprüfung.