> There is no progressive enhancement way around this issue, and an opt-in string doesn’t do the job either. In essence, we break backwards compatibility of scr

> There is no progressive enhancement way around this issue, and an opt-in string doesn’t do the job either. In essence, we break backwards compatibility of scripting of the web. This could be not a big issue, if browsers supported ES6, but we’re not quite there yet. This post misses the single most important tool for users (to help them try syntaxes), framework developers (to help them be more productive and consistent), and standards developers (to get feedback): Transpilers. Because much of ES5 is reflective (and ES6 even more so), it makes a great target for the translation of a new syntax into old syntax. This cycle of reflective-api-to-new-syntax is exactly what Yehuda is talking about in his post http://yehudakatz.com/2013/05/21/extend-the-web-forward/ http://yehudakatz.com/2013/05/21/extend-the-web-forward/. The impact of transpilers on ES module syntax, ES classes, and ES promises as been amazing. You can see the same thing happening with decorators/annotations today- real world use in TypeScript is influencing the discussions of TC39. > The current support table of ECMAScript6 in browsers, parsers and compilers doesn’t look too encouraging. A lot is red and it is unknown in many cases if the makers of the products we rely on to run JavaScript will take the plunge. I disagree in the strongest terms. ES6/E2015 is a huge amount of changes, and browsers have been driving the discussion and implementing items as they have stabilized.