Wow, var was so broken.<p>Anyway, we use as much ES6 as Node 4 allows at work. Transpiling on the server never made much sense to me. I also used to sprinkle the fat-arrow syntax everywhere just because it looked nicer than anonymous functions, until I realized it prevented V8 from doing optimization, so I went back to function until that's sorted out (I don't like writing code that refers to `this` and never require binding, so while the syntax of => is concise, it is rarely used as a Function.bind replacement). Pretty much went through the same experience with template strings. Generator functions are great.<p>I'm not a fan of the class keyword either, but to each their own. I think it obscures understanding of modules and prototypes just so that ex-Class-based OOP programmers can feel comfortable in JS, and I fear the quagmire of excessive inheritance and class extension that will follow with their code.
> Unlike var, let and const statements are not hoisted to the top of their enclosing scope.<p>No, let <i>is</i> hoisted to the top of the enclosing scope [1] ("temporal dead zone" notwithstanding). let, however, is not hoisted to the top of the enclosing <i>function</i>.<p>[1]: <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...</a>
I would recommend taking a look at this page for a bigger "cheatsheet": <a href="https://github.com/lukehoban/es6features#readme" rel="nofollow">https://github.com/lukehoban/es6features#readme</a>
I love how concise this is an handles a lot of "Gotchas" when working with ES6, but can we call a spade a spade and NOT call this a "cheatsheet?"<p>I always imagine cheatsheets to be just that; something I can render on one sheet of paper. Printing the entire raw README text would take 4 pages (2 sheets, front and back).<p>I think it would be better titled, "ES6 best practices" since I think that's a more accurate description of what it is.
Great reference and overview of ES6.<p>One minor quibble. I was bothered by the misuse of the words "lexical" and "interpolate". The lexical value of the keyword "this " is the string "this". Then, you might translate between two technologies such as CommonJS and ES6 but interpolating between them implies filling in missing data by averaging known values. Granted this word is commonly abused. Sorry this is a bit pedantic but these corrections would improve the document, IMO.
The only thing from this list of new ES6 idioms that doesn't sit comfortably with me is the short-hand for creating classes. I remember being kind of blown away way back in the day with the prototypical/functional nature of Javascript and how you could wrangle something into being that behaved in an object-oriented manner just like other languages that had explicit class declaration and object instantiation.<p>Part of me feels that obscuring Javascript's roots in this respect is very un-Javascript-y. What think ye?<p>Coming from Ruby, loving template literals, feel right at home with them, I wish even C could have them (if that makes any sense!).
Is "WeakMap" really the suggested way to implement private class properties?<p>Using "this" as a key into a Map of private variables looks bizarre. I would rather keep my code concise than create a layer of obfuscation.
This cheatsheet is wrong about ES2015 modules. They don't define how module loading works, that's still being worked on [0]. ES2015 just defined the syntax.<p>[0] <a href="https://github.com/whatwg/loader" rel="nofollow">https://github.com/whatwg/loader</a>
[This](<a href="https://ponyfoo.com/articles/es6" rel="nofollow">https://ponyfoo.com/articles/es6</a>) is also a very informative guide of ES6. I highly recommend perusing it.
Two questions: what happens if you use ES6 standards in a browser that does not support it?<p>And would it be wise to hold off adopting until all browsers support it?
"Require" is the reason why we now have a module for just about anything in Node.JS. I even think Kevin Dangoor or whoever invented it should get the Nobel prize. But then the ES committee choose to use paradigms from year 1970. I cry every time someone use import instead of require in JS because they miss out why globals are bad, modularity is good, and the JS API philosophy (super simple objects with (prototype) methods).
This will likely get downvoted - but I have just realized how much I was underestimating the privilege of developing apps in Dart instead of JavaScript. Dart had none of the mentioned idiosyncrasies from day one, all the features, and has a lot of other stuff (like async/await, yield, mixins, etc) to offer. Its tooling is very simple and powerful, and the overall experience is really nice - when there is a problem, it's always in the logic of my code, and not things like some weird implicit conversions that are so common in JS land. I almost forgot how terrible JS is...