I'm surprised by the state of const/let nowadays.<p>The well-known good practice: use const by default; use let when it's needed. At the release of ES6, it was the way to go. But everyday I notice libraries—and some really famous— that use let everywhere in their docs, or some really influent developers from Google or Facebook who share samples of code on Twitter using let when it's not needed [1]. I don't know why. Seems like most people now think that const is for declaring constants (in the traditional meaning, like const API_URL) when it's just the normal way to declare variables that don't need to be reassigned (so basically most variables).<p>Dan Abramov said: "some people say const is ugly" [2]. Well, if it's a matter of appearance...<p>[1] <a href="https://twitter.com/addyosmani/status/789126892402204673" rel="nofollow">https://twitter.com/addyosmani/status/789126892402204673</a><p>[2] <a href="https://twitter.com/dan_abramov/status/783708858803978240" rel="nofollow">https://twitter.com/dan_abramov/status/783708858803978240</a>
The most interesting part about template strings was skipped over: tagged template literals. You can prefix a template string with a function which will get called with the list of string parts and the values passed in ${...} parts, and then it's up to the function to choose how to join the values up into the resulting string (or hell, you could make it return something besides a string if you want). The function can even access the raw version of the string containing any backslash escapes in it as-is. The default `String.raw` function is handy if you're writing something like an SQL query with a few \ characters that need to be in the final query. Both of these strings are the same here:<p><pre><code> const a = "SELECT id FROM foo WHERE name CONTAINS r'\\n'";
const b = String.raw `SELECT id FROM foo WHERE name CONTAINS r'\n'`;
</code></pre>
You could even assign `String.raw` to a variable first, and then make strings look like raw string literals of other languages:<p><pre><code> const r = String.raw;
const s = r`SELECT id FROM foo WHERE name CONTAINS r'\n'`;
</code></pre>
Another good use of template strings is automatic HTML encoding (with a small module of mine on npm): <a href="https://www.npmjs.com/package/auto-html" rel="nofollow">https://www.npmjs.com/package/auto-html</a>
For those using Babel already or want to use ES6+ on a set of supported browsers: we have started work on <a href="https://github.com/babel/babel-preset-env" rel="nofollow">https://github.com/babel/babel-preset-env</a>. Would appreciate more testing!<p>It allows passing in a set of supported browsers and transpiling what is required using the lowest common denominator env (uses <a href="https://github.com/kangax/compat-table" rel="nofollow">https://github.com/kangax/compat-table</a> for data).<p><pre><code> // .babelrc with preset options
{
"presets": [
["env", {
"targets": {
"chrome": 52,
"ie": 11,
"browsers": ["last 2 versions", "safari 7"]
}
}]
]
}
</code></pre>
If you have questions, ask below (or make an issue)
"you can start using it right now" if you don't care about IE8, IE9, IE10, and many mobile browsers and are willing to ignore 20% of your customers.<p>e.g: <a href="http://caniuse.com/#search=let" rel="nofollow">http://caniuse.com/#search=let</a><p>const does not have block scope in those browsers either, but will work, adding to your debugging confusion.<p>template literals and multiline string has no IE support at all (you need edge: <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...</a>) so you can forget most most enterprise clients<p>Similar things are missing for most features from the article.<p>I wonder how many JS dev have to answer to actual customers because none of my clients in the last decade who would have accepted to have a possible failure on 1/5 of their visitors. Are they all bloggers or working in hype start ups ?
I always turn to an ES6 article on babeljs.io when I check out ES6 features.<p><a href="https://babeljs.io/docs/learn-es2015/" rel="nofollow">https://babeljs.io/docs/learn-es2015/</a><p>One of the features I like is default parameters. I'd like to add a usage that isn't mentioned in the article. It's really handy to pass optional parameters since default parameters can be nested.<p><pre><code> class Hoge {
foo({active=true, collapsed=false, silent=false}={}) {
}
}
let hoge = new Hoge();
hoge.foo({collapsed: true});</code></pre>
On the web browser side, I don't recommend using ES6 yet, without any kind of fallback. Internet Explorer 11 is still used, as are devices on older iOS versions.
(without counting people using the default browser on pre-Lollipop Android)
While I'm a big believer in most of the ES6 changes (arrow functions! let/const! classes! generators!), I am not a big fan of many of the new destructuring features. They can actually make your code less approachable if you don't already know what's going on.
> Because even though the if-block is not executed, the line 4 still redefines var x as undefined.<p>This is because of hoisting. Not quite right as described.
Appreciate the article, but this is relatively dated information. While I can see that many enjoyed the article, many have also been working in ES6 for over a year now. If you're ready to join, I highly suggest everyone make their way to <a href="https://babeljs.io/" rel="nofollow">https://babeljs.io/</a> and everything it has to offer resource-wise or tooling-wise.
"best practices": "use class instead of manipulating prototype directly"<p>Who comes up with these "rules"? This is not a hard and fast rule. Manipulating the prototype of an object is not "dangerous".<p>I'm sick and tired of some loud mouth saying something is dangerous without explaining why. WHY? Why it it dangerous? Don't talk at me. Provide me a sound reason and case to justify what you say. Talk is cheap.<p>It makes me not trust anything else in this article when someone is flippant.
Ugh. All this "make Javascript like Java" stuff needs to stop.<p>Cool stuff: Tail call elimination. Arrow functions. Assignment spread for multiple return values and "rest" / default parameters. Proxying (combined with computed get/set on properties) for easy decoration.<p>Classes and let: meh.
I have a question:<p>What does `for element of arr` buy me over `arr.forEach(element => ...)`<p>I don't find the for...of syntax particularly appealing or useful, but I might be missing something. Is it a matter of preference?
I gave a more complete overview of ES6 (and ES2016 and so on) features at a user group last month. Slides:<p><a href="http://files.meetup.com/11421852/WhatsNewInJavaScript.pdf" rel="nofollow">http://files.meetup.com/11421852/WhatsNewInJavaScript.pdf</a><p>The slides are mostly code examples and I tried to go for completeness rather than detail, so there are some mentions you don't normally see in these overviews (e.g. the article doesn't mention proxies).
Equally spacing the points on the timeline may make for an aesthetic image, but it fails to illustrate the author's point. "As you can see, there are gaps of 10 and 6 years between the ES3, ES5, and ES6. The new model is to make small incremental changes every year." No, we can't see. In that pretty graphic, ES5->ES6 is exactly the same distance as ES6->ES7.
If someone wants to dig more on ES5 vs ES6 , check this presentation (use side arrow for navigation) <a href="http://coenraets.org/present/es6/#1" rel="nofollow">http://coenraets.org/present/es6/#1</a>
Probably add pointers to where the images were taken from.<p>Ex:<p><a href="https://kangax.github.io/compat-table/es6/" rel="nofollow">https://kangax.github.io/compat-table/es6/</a>
Great article!<p>It would be fantastic to make all the code snippet interactive with the klipse plugin.<p><a href="http://blog.klipse.tech/javascript/2016/06/20/blog-javascript.html" rel="nofollow">http://blog.klipse.tech/javascript/2016/06/20/blog-javascrip...</a>
If you want to learn ES6 I highly recommend the Tower of Babel interactive tutorial: <a href="https://github.com/yosuke-furukawa/tower-of-babel" rel="nofollow">https://github.com/yosuke-furukawa/tower-of-babel</a>
var's function scope is a feature! You don't have to place variable declarations in the header! (they are hoisted) Placing the var declarations where they are used makes the code easier to understand.<p>The point of constructor functions is not having to write <i>new</i>. So classes does nothing besides syntactic sugars over the prototype system, witch actually makes it more complicated and the code harder to maintain.<p>Async programming <i>is</i> hard, but not because of callbacks. Promises is just a wrap around callbacks, witch just adds complexity and more boilerplate. It will get better with async/await but I will still prefer simple callbacks.<p>Arrow functions are very nice for one liners, but will ruin your code if you use them everywhere instead of named functions. You should always name your closures, then it's easier to debug and lift them out.
<i>destructing is very useful and encourage good coding styles</i><p>Is it? Personally I'd say that was bad code. What so wrong with using the original objects?<p>Putting aside the need to variable swap once a year or so, all the other examples look really confusing to me and unclear what they're doing. The `Deep Matching` especially.