ES6: The features I'm most excited about

Hm, at first glance I am as well, especially with tagged template strings. Those look particularly simple but powerful.

Generally though, is it reasonable for features such as these to be included at the language level? I primarily use ES5 JavaScript so I'm used to pulling in a decent amount of modules (in this case handlebars, underscore, etc.) for things like templating.

But I will be relieved to have a language-standard solution to what feels like such a common problem for the environments in which JS is used primarily, despite the tradeoff that's made in accessibility due to feature bloat.

is there pythonesque """ """ triple quotes for literal whitespace?

While my example isn't an issue in ES6, most of the controversial came from CoffeeScript. Using classes comes with classical inheritance expectations. In CoffeeScript, changing class variables would carry through all instances, and that is unexpected from a classical inheritance point of view. However, it made complete sense in the compiled JS.

It is more the "extends" than "class" that is controversial because it eschews other pattern like mixins.

In es6 it's finally possible to properly subclass internal types, it properly separates Class properties and prototypes, and it allows users to extend arbitrary classes.

My problem with promises is that delivering it without async/await is just awkward. Because, yes, in the ES7 async/await world, you're going to want to use promises heavily because they'll work so great with that.

But in the ES6 world, making your API promise-based makes it heavier-feeling and more awkward than simple, clean callbacks. (Which get an unnecessarily bad rap from people who don't work primarily in JS; there are cases when callbacks get awkward, but just looking at code that's four levels of indent deep and declaring it "callback hell" -- as you so frequently see -- is a super-shallow analysis. That code is clean and easy to understand, as often as not.)

Thanks, fixed.

I think it's fair to say that people who want to write object-oriented Javascript are very excited by class. Those of us who have found that the non-OO nature of Javascript is part of what makes it so productive are... much less excited.

Why can all this new syntax be added, but the "use strict" pragma is still specified by a string? It made sense to send messages to the interpreter in a backwards compatible way, but now it just seems odd.

> he is most excited about destructuring `let { name, age, gender } = user;`.

Why is this a big deal? Seems pretty trivial.

I'm with him, I'm pretty excited about destructing coming to JS. If it's half as powerful as it is in clojure it'll be great.

Fat arrows are increasingly becoming one of my favourite additions.

No more `function() {}.bind(this);` since `() => {};` is equivalent. It makes it clearer for the reader that the code block inherits scope.

Can someone explain the reasoning behind having any kind of backwards compatibility? Who would pick a worse-but-compatible ES6 over a better incompatible version?

For example, the scoping rules: why have two separate scoping rules for let and var? To put it another way, would ES6 have let and var with differing scoping rules if it was designed today? If not, then it's a flaw (any difference from what a clean redesign would look like I consider a flaw).

Why not just make a simple and consistent syntax?

> I'm a bit worried about ES6 making the language harder to understand.

Welcome to C++.

Of course, with proper tail calls, you can get generators and any kind of control structure almost for free :)

The problem with Javascript generators, however, is that you're not allowed to call other functions from them, which yield. This very much limits the kind of async stuff you can do with them.

With the introduction of arrow function you won't need to use .bind(this) as arrow functions capture in their lexical scope the variables/keywords: this, arguments, super.

e.g.

setTimeout(function(){alert(this.a)}.bind(this));

becomes simply

setTimeout(() => alert(this.a));

There is a proposal for a :: bind operator.

1. a unary :: operator for binding methods to their objects: `foo.then(::console.log)`

2. a binary :: operator for chaining: `x(a)::y(b)` (equivalent to `y.call(x(a), b)`)

async/await solves error handling and hanging onto values quite nicely.

IMO you should use Babel and take advantage.

Throw an Error to reject it.

There is a way to reject it in the .then() callback. You just throw.

.then() does create a new promise. Return Promise.reject() in the fulfillment function to reject the new promise.

  somethingThatReturnsPromiseWithoutError()
    .then((res) => {
      return Promise.reject("some error");
    })
    .catch((err) => {
      console.log(err); // => some error
    });

Promise.resolve() and Promise.reject() return a promise resolved or rejected to the value passed in the first argument. Returning a promise in the fulfillment function passed to .then() chains the promises together.

  somethingThatReturnsPromise()
    .then((foo) => {
      return foo.bar;
      // Or if you like it more verbose
      return Promise.resolve(foo.bar);
      // Or pass bar to a function modifying bar that returns a promise
      return modifyBarReturnPromise(foo.bar);
    })
    .then((newBar) => {
      console.log(newBar);
    });

In your case, if you need step1Val in next promise chain, I personally do this, however people more familiar with promises may know of a better way to do it (maybe with something like Promise.all() or Promise.props() in the BlueBird library).

  somethingThatReturnsPromise()
    .then((first) => {
       doSomethingWithFirstAndReturnPromise(first)
         .then((second) => {
           console.log(first + second);
         });
    });

I like Jquery's Deferred better then ES6 Promise. Promises lack the `always` callback, they don't have any `progress` events.

The spec on mdn[0] doesn't mention asynchronous `then` or `catch` behavior. If the callback in Jquery `Deferred#then` returns a Deferred that deferred will be returned by `then`.

    // Basic async function, resolves after n milliseconds
    function wait(n) {
      var promise = $.Deferred();
      setTimeout(promise.resolve, n);
      return promise;
    }

    wait(10)
      .then(function() {
        console.log('first');  // prints first after 10 milliseconds
        return wait(10);
      })
      .then(function() {
        console.log('second'); // prints second after 20 milliseconds
        return 'done';
      })

You can 'flip' a failed promise by returning a resolve promise in the fail callback.

    var promise = $.Deferred();
    setTimeout(promise.reject, 100)

    promise.then(null, function () {
      return $.Deferred().resolve([]);
    }).done(function(arg) {
      console.log(arg); // Prints '[]'
    })

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

You can reject inside a `then` by `throw`ing an error, like synchronous try-catch.

You don't need resolve or reject. Just return the promise:

  .then(val => doSomeStuff())

Thats it. The resulting promise will get resolved/rejected based on the return result of doSomeStuff()

You can also use throw to reject a promise manually, or return Promise.reject()

  .then(val => {
    if (something) return successVal;
    else throw new Error("Failure");
  });

For more complex scenarios where I need the values from previous actions, I like the forgoing the chaining and using a join helper to unwrap any set of promises as needed:

  let url  = getUrl(resource);
  let data = url.then(url => fetch(url))
  let updateData = d => _.assign(d, {field: 'newVal'}
  let update = join(url, data, (url, data) => sendUpdate(url, updateData(data))

Yes, a lot of the new features are very "about time" but that doesn't remove the excitement to now have them as a part of JavaScript.

'this' without arrow functions is currently a huge source of confusion. I feel like the arrow functions will help to alleviate a lot of that confusion.

What exactly did you have in mind other than "new Promise()" to create a promise?

Most of the time the object you'll be awaiting will be a promise.

There is no harm in either. Overall, just have fun and learn JavaScript :)

ES5 is the current standard in all major browsers, so using its functionality could be considered "safe". Thankfully we have transpilers (will convert your ES6 code to ES5), so you can use ES6 features in production today - just remember they are converted to an ES5 implementation of said functionality.

Whether you're writing 5 or 6, it's still worth looking at and getting familiar with the various Javascript build tools (Grunt, Gulp etc). They're an increasingly important part of a Javascript developer's toolset, and using them to transpile 6 to 5 will get you off to a good start.

Sure that works too, plus its a great way to point out initializing default arguments.

It allows web APIs built-in to the browser to return a promise, e.g. audioContext.decodeAudioData(data).then(...). If you just used a library, the browser wouldn't know how to wrap the returned value in a promise. It also guarantees interoperability between all APIs using promises, avoiding any incompatibility between different libraries.

Paving the cowpaths. Promises were already standardized before ES2015 arrived, but now you can just write libraries using promises without having to rely on the developer providing their promise implementation of choice. This also prevents scenarios where you might end up with N different promise implementations because you're using N libraries, each depending on a different promise module (e.g. bluebird, Q, jQuery.Deferred, AngularJS $q, etc) all of which are slightly different.

This also means more feature-rich implementations can just extend the native promises instead of implementing everything from scratch, though for me this pretty much spells the end of third-party promise implementations.

In other words, they've been added for the same reason as the various new helper methods: not because they add new functionality, but because they provide a reliable well-defined and consistent solution to a very common problem.

There is one in the addIt function.

The other features? Already being done: https://kangax.github.io/compat-table/es6/

Modules? That may be a while, and isn't a big concern since until HTTP2 is in wide effect (which may be really soon anyways) it makes more sense to just package the files in to one file (which you can do right now) using Browersify, JSPM, Webpack, or what have you than having the client request a whole bunch of javascript files at once.

I'm working on a JavaScript editor. But doesn't understand. Can you be more elaborate!?

Yup. It's as if coffeescript was created by one person (and a bunch of great PRs!), while ES6 came out of a committee.