That seems quite a negative view. The features mentioned in the article are only a small part of what is coming in ES6.[1]

The “fat arrow” syntax for defining anonymous functions is much shorter and neater than the cumbersome notation we’ve had in the past:

items.map(function (item) { return do_something_with(item) })

becomes

items.map(item => do_something_with(item))

and there are both expression and statement variations of fat arrow functions, so we don’t need the return in this sort of situation either. There are also some other significant differences, particularly in what “this” means within the anonymous function.

Combine that cleaner notation with the introduction of generators[2] and we can have lazy fluent interfaces for transforming data efficiently, along the lines of:

items.map(item => item.interesting_property)
.filter(item => is_wanted(item))
.reduce((item1, item2) => combine_usefully(item1, item2), initial_value)

It’s not yet completely clear how we will take advantage of these possibilities in standardised ES6, because being backward compatible is a priority so you can’t just make sweeping changes like having all the existing Array.prototype functionality become lazy. This article[3] gives some ideas of how the kinds of utility library we’ve used in the past might look if they were written to take advantage of ES6’s new features, and presumably even if ES6 doesn’t include this kind of generator-based lazy functionality as standard it won’t take long before libraries are written to do it if they haven’t been already.

Incidentally, that emphasis on backward compatibility also explains the use of back-ticks for strings with substitution. You need a new syntax that doesn’t change any existing behaviour, so regular single- and double-quoted strings can’t be used.

There’s a lot more to ES6 besides just these areas. The article and this HN discussion are simply concentrating on some of the more interesting data-munging parts of it. For example, it also finally has a useful module system.[4] It really is quite a step up from today’s JavaScript in actual use; perhaps a good analogy would be the shift from Python 2 to Python 3, where the older version still does a decent job but a lot of little details are better in the newer one and the cumulative effect feels like a qualitative improvement in the language.

[1] In practice, these features are already available today with only a small amount of effort, because you can use a transpiler like 6to5 or Traceur to convert ES6 code into ES5 that will run quite happily in any modern browser. These transpilers are straightforward to install and literally a one-liner to run, similar to installing SASS to convert an SCSS stylesheet to CSS for use in the browser. They are already integrated nicely with most other popular tools like Gulp, Grunt and Browserify. At worst you need a polyfill for a few features, but for example 6to5 provides one polyfill that does everything, so again this is a very simple thing to incorporate into your project if you do need it.

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[3] http://aaronstacy.com/writings/if-underscore-was-written-in-...

[4] Very sensibly, the transpilers used to work with ES6 today can just turn those ES6 modules into AMD or CommonJS modules for compatibility with other existing tools. For example, you can use a 6to5 plug-in with Browserify, and it will convert ES6 modules into CommonJS ones that Browserify itself can then work with in the usual way. Again, this is yours for the price installing the plug-in using npm and an extra command-line option to Browserify, or something similarly straightforward using other package managers/build tools.