That's an extraordinarily reductive view of improvements to a programming language. A basic example: cleaner syntax for anonymous functions will have (presumably) almost no effect on speed/memory either which way, but will make code more readable. Which is not a 'hipster' concern.

It's the difference between

  var map = function (f) {
    return function (list) {
      return list.map(f);
    };
  };

and

  const map = f => list => list.map(f);

Also: "this" is bound for you in fat arrow functions without having to resort to function.prototype.bind or "var that = this;" trickery. That's an issue I've seen bite many people before and it'll be nice to have an easy way to avoid that.

Upvoted your comment so that everyone can see it.

ES6 has template strings, destructuring assignment, Map and Set data structures (and more). While you're right and it is not NEEDED, this is something that dramatically improves on the weakest aspects of ECMASscript.

Based on your comment, it feels like no addition is ever a good addition if you can express it with the building bricks you already have. With such a way of seeing things, we'd all be coding with assembly language, cause nothing really affects speed or memory consumption for the better.

No-no, there has been lot of features added to Javascript (i started writing it around 2003) that were not shimmable in earlier versions.

One reason to rule them all: Generator functions.

Why it is a big deal one might ask. It is the BIGGEST deal in history of Javascript in my book because it allows you to do async that looks sync. No more callback hell. It is the single most important feature, as it eliminates async issues completely. And EVERYTHING in js is async. But in reality, you want to drop into async only sometimes. Now you are forced into it 100% time, even when you need the result of async call to decide what to do next. It gets tricky really fast.

Well promises help. And then they stop :). Stop helping. They just break under the weight. If you have promise chain that gets too long, you will feel the pain.

The whole thing is, when some IO returns 1 or 2. And your next step is to do a or b depending on the reply. How is your neat promise chain looking now? Then repeat 100 times :(

Not even mentioning error handling... and stack traces.

So i do agree that it depends what you do a lot. Maybe there are domains where it is not important... but i still need to see that one.

And i will take blocking IO with try/catch 10 times out of 10. Even when it is not critical. It is just nicer and easier to reason about.

require('bluebird').coroutine function*() {}

Promises + Generators = The sweet spot.

Check out https://www.npmjs.com/package/coroutiner to make it stupid-easy to coroutine your entire app.

That is one perfectly fine way to do it. But that is exactly what i want to highlight. The generators. You can combine them with promises, callbacks, even the CSP channels. But you need the generator. That is where magic happens and no amount of library code will do that for you, one needs compiler support (or a macro...)

Promises are certainly better than promise-free 2005 style callback code, but they do require that you reimplement language features like try/catch. Yield allows you to do asynchronous try/catch, which doesn't depend on some library getting the implementation right (libraries often lump rejections and thrown exceptions together) and looks more sensible anyway.

There are other advantages to yield as well. Entire design patterns like CSP aren't possible without it.

Proxies. You can't shim in the Proxy object. Ain't no hipster feature there.

You can't even transpile it without massively different output from the transpiler, which is a bit bad.

Map and set are much nicer in ES6 as built in objects.

> but really why not convenrt them to string represntation and put to simple object?

Because as soon as you might have "toString" or "__proto__" as a key things go all haywire.

Why do all these strange workarounds?