Hating on Javascript is one of the trendiest things to do in online tech-centric communities.

The future of Javascript is bright, and the new features added are vast improvements onto a language that stagnated far too long. Many of the criticisms towards the new features are not well thought out. Luckily the TC39 committee is full of extremely intelligent developers who have a good understanding of the nuances in adding new features.

On the other hand, there are at least some that have been coding in JS for a long time and loved the simplicity and yet versatility of the language. And there's a feeling of some of this being lost in the latest iterations of the standard. To be fair, I would rather observe this criticism in a RISC vs CISC context. (With ES6, JS is definitely taking a rather CISC-like direction.)

It's a fair point. In fact, I wrote a javascript library, http://intercoolerjs.org, to avoid writing a lot of javascript, so I have a somewhat ironic relationship with the language.

On the other hand, I also work on Gosu (http://gosu-lang.github.io/) which is has its own kitchen sink issues, so I believe I'm not being a troll, or at least not simply being a troll, when talking about language design.

Overall Javascript even with ES6 still seems like a fairly immature language. It is a definite step in the right direction though. Specifically:

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.

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.

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...

while i agree that everything mentioned in the article is useful, i think ES6's import is horrible. why do i have to look at (potentially outdated, esp. in js world) documentation or look at the code to know whether or not to do

  import Foo from 'bar';

or

  import { Foo } from 'bar';

I think it was a PITA to learn, but it's also very necessary to interoperate with the existing JS ecosystem. Many libraries have a default export (often, a function) and then a number of sub-exports that are assigned as fields of that. Without the distinction you mention, there'd be no way to specify whether you want to import 'bar' and bind it to Foo, or whether you want to import the Foo member of bar.

Given an extra few days to learn the semantics of import vs. losing access to the millions of npm packages out there, I'd rather spend the extra few days.

I find it fairly intuitive. The former is for importing the default module, while the latter is simply using the ES6 destructuring syntax to import specific named modules.

and how do you know whether or not for library X you need to import the default export or one of the named exports without looking at documentation? furthermore, you have to remember which to use for every library because there's not a lot of consistency among libraries

i think syntactically the destructuring syntax for imports is cool and clever, but in practice i find it annoying to use

For most of the libraries I've used so far, they generally seem to follow the convention of having the entire library in a single object as the default export while also exposing each individual function/property as named exports.

In the case that they don't, I generally just try "import * as Foo" to find out exactly what the library exports. Not saying this is ideal, but it really isn't too bad either, in my opinion, considering the flexibility and conciseness this approach offers for the general case.