A: ECMAScript Harmony
Nicholas C. Zakas · 2015
With the renewed interest in web development since 2004, conversations began taking place among browser vendors and other interested parties as to how JavaScript should evolve.Work on the fourth edition of ECMA-262 began based largely on two competing proposals: one for Netscape's JavaScript 2.0 and the other for Microsoft's JScript.NET.Instead of competing in the browser realm, the parties converged back into ECMA to hammer out a proposal for a new language based on JavaScript.Initially, work began on a proposal called ECMAScript 4, and for a long time, this seemed like the next evolutionary step for JavaScript.When a counterproposal called ECMAScript 3.1 was later introduced, it threw the future of JavaScript into question.After much debate, it was determined that ECMAScript 3.1 would be the next step for JavaScript and that a further effort, code-named Harmony, would seek to reconcile some features from ECMAScript 4 into ECMAScript 3.1.ECMAScript 3.1 was ultimately renamed to ECMAScript 5 and standardized fairly quickly.The details of ECMAScript 5 have been covered throughout this book.As soon as ECMAScript 5 was fi nalized, work immediately began on Harmony.Harmony tries to keep to the spirit of ECMAScript 5, in making more incremental changes rather than radical language changes.While the details of Harmony, aka ECMAScript 6, are still developing as of 2011, there are several parts of the specifi cation that have been fi nished.This appendix covers the parts of Harmony that will defi nitely make it into the fi nal specifi cation, though, keep in mind that the details of the fi nal implementations may change from what's presented here. GENERAL CHANGESHarmony introduces several basic changes to ECMAScript.These aren't major changes for the language but rather the closing of some of the curiously open gaps in functionality.