Netscape 4 had dynamic HTML entities bound to JS ("&{...};"), which were resolved by the rendering engine. I think, it would have been interesting to revive this approach.
Other, one thing I often observe in ES6 examples is replacing quite complex constructs that could have been expressed much simpler using older JS standards. E.g., "Array.prototype.push.apply(arr1, arr2)", where "arr1.concat(arr2)" would have done fine. Not too sure, what this means for real-life applications, but there's definitely a trend in expressing things in artfully complex ways.
The template literal "fail" (which is really just static scoping) is necessary to make JS JITting anywhere near reasonable. You may not care about JS runtime performance, but lots of people do.
Re:ES6 is beautiful
by CuriouslyC on Thursday April 07, 2016 @04:06PM
(#11450203)
Or they could have just made template literals be multi-line strings, and added an eval method, taking an optional context object which could override local names. That would have been a lot more useful...
I think the lambda syntax is nice and concise, although the disconnect between an implicit return with a bare statement versus required explicit return with braces is kind of silly. They should have made it just implicitly return the evaluated value of the last statement in the lambda all the time.
The de-structuring syntax is less clear and consistent than, for example, Python's. The fact that both array-like things and object-like things are de-structured using '...' means that you have to consider the context when you see it, and you could probably construct cases where it isn't clear exactly what is going on.
Template literals are obnoxious because they bind when declared. This means you can't pass a template literal around to be evaluated later. You could wrap it in quotes and use eval, but then you lose multi-line support. Pretty fail.
The fact that module support is finally part of the language is a good thing. Not having a built-in module system is probably the biggest embarrassment in the language. Now we just need a dependency manager built into the browser so people can require jQuery >= 2.0 for instance, and we won't have to worry about CDNs and what not.