Wow. I can't believe template strings (<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/template_strings" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...</a>) aren't in this list. I'm incredibly excited to start having those at my disposal.
I don't understand why everyone considers classes controversial. If you look at code in the wild, it already does what classes desugar to: everyone already writes constructor function and attaches properties to their prototypes.<p>At least now with classes, users coming from other languages wont be as tempted to make their own completely incompatible object systems.
My favourite feature is promises, while it doesn't add a new syntax and you can probably add a library for it, the fact it's standardised makes a world of difference. Now that it's standardised<p>1. It will become the common interface for deferred operations and library authors can make assumptions that it's there.<p>2. ES7 Async/Await will be able to leverage this common interface.
Even better: The arrow function example used the statement form of an arrow function, instead of the expression form, which allows you to omit the return:<p><pre><code> // using arrow
var adder = {
num: 2,
nums: [1,2,3,4,5],
addIt() {
return this.nums.map(n => this.num + n)
}
};
console.log(adder.addIt()); // [3, 4, 5, 6, 7]
</code></pre>
I'll concede that the arrow function is a bit overly complicated, with this, sometimes-optional argument list parenthesis, and object literal/function body syntax ambiguity.
The first module example is incorrect:<p><pre><code> // myModule.js
export function myModule(someArg) {
return someArg;
}
// main.js
import myModule from 'myModule';
</code></pre>
The import is importing a non-existent default export. Either the export needs to be changed to a default export:<p><pre><code> export default function myModule(someArg) {
</code></pre>
-or- the import needs to be changed to importing a member:<p><pre><code> import {myModule} from 'myModule';</code></pre>
I was just talking to my friend who works at NetFlix on the frontend team about ES6, he is most excited about destructuring `let { name, age, gender } = user;`. I however advocate that the new class syntax is the best part of ES6. Take the following trivial OOP example, which I think reads so much easier a lot like PHP.<p><pre><code> "use strict";
class Vehicle {
constructor(name) {
this.kind = 'Vehicle';
this.name = name;
}
printName() {
console.log(this.name);
}
}
class Car extends Vehicle {
constructor(name) {
super(name); //call the parent method with super
this.kind = 'Car';
}
}
let myCar = new Vehicle('Mercedes');
console.log(myCar);</code></pre>
ES6 is a mixed bag for me.<p>I'm against block scope in a way. It's semi-useful, but it's just sugar. So many features of ES6 seem to be designed for people who don't want to bother learning javascript: classes, block scope, arrow syntax, etc. It's just trying to shoehorn javascript into the template every other language follows when javascript is <i>not</i> every other language.<p>That being said, I like iterators, weak maps, typed arrays, TCO, and so on.
I'm a bit worried about ES6 making the language harder to understand.<p>For example, scoping: For backwards compatibility reasons, var has to stay function scoped. But now we also have let, which has different scoping rules. Also, Symbols: [Symbol.iterator]() - what? Why?!<p>On the other hand, stuff like arrow functions, template strings, modules and tail optimization are awesome.
I agree with this list completely, but it doesn't mention one of the best reasons generators and promises are awesome: async/await-style asynchronous programming eliminates callback hell by letting you write asynchronous code as if it were synchronous, including using control structures like conditionals, loops, and try/catch.<p>And you can do it in (most) browsers today using a transpiler like Babel and a library like Blurebird, Q, co, or task.js.<p>The rest of the things are nice, but promises/generators (and eventually async/await) are game-changers.
I think .bind(this) could be added as a (more common?) alternative example to var self = this;<p>Personally I'm most excited about the module system. It's by far the most confusing thing for our students (and hard to google since you end up going down the rabbit hole of build systems etc.)
Coroutines are the game changer imo. I wrote a little presentation to illustrate code flow: <a href="http://afc.neurosnap.net" rel="nofollow">http://afc.neurosnap.net</a>
I've just been playing with Promises and like them a lot. But one thing I find strange is that ".then()" creates a new promise, but with no way to reject it.<p>ie. I can't write:<p><pre><code> return new Promise((resolve, reject) => {
// Do some stuff, call resolve()/reject() on success/failure.
}).then((step1Val, resolve, reject) => {
// Do some stuff, call resolve()/reject() on success/failure.
// But this doesn't actually work, because the "then" callback
// doesn't get resolve/reject as args.
});
</code></pre>
Instead I'm having to write this as the following, which is more verbose:<p><pre><code> return new Promise((resolve, reject) => {
// Do some stuff, call resolve()/reject() on success/failure.
}).then(new Promise((resolve, reject) = {
// Do some stuff, call resolve()/reject() on success/failure.
// But this way I don't get access to step1Val.
}));
</code></pre>
Another bummer of this style is that that the second step doesn't get access to the first step's value.
Although arrow functions are nice, they've been around in the form of lambda expressions in C# and other languages for some time, so the initial reaction was more of a "about time" rather than a "wow!" for me. Same goes for generators/yield keyword.<p>Thanks for pointing out the key difference between arrow functions and inline functions being the context of 'this'. 'this' is going to be a source of confusion for a lot of people.
Now just throw away the DOM, replace it with something more suitable for applications instead of documents, and we can have something akin to Smalltalk back.
I was a little confused by the constructor for Player in the class example. Wouldn't the following be more appropriate:<p><pre><code> constructor(x = 0, y = 0) {
this.x = x;
this.y = y;
}
</code></pre>
(i.e. this way if "new Archer('Legolas', 5, 6);" the x and y values will not be ignored.)
What's the point of promises being part of ES6?<p>I understand them and use them quite a bit. I just don't understand why they're in the language spec. They don't add anything new to the language (<i>vs say generators or symbols</i>).<p>Is it purely for performance?