One of the biggest sources of bugs and confusion in JavaScript has been variable scoping. Without var everything was global, with var it was better but still weird. ES6 brings us let and const with proper lexical scoping, which makes it easier to understand where a variable is and isn't defined.

One of my favorite features present in most modern JavaScript codebases is omitting repetitive object keys. I don't think this is quite in the standard yet, but it works in most React-based codebases via Babel. I include it because it's commonly used in the wild.

Destructuring is another magnificent feature. It gives you a convenient syntax to extract values from objects and arrays. Using it feels kind of like drawing the shape of your object, and JavaScript filling-in the blanks.

Now this, this is the workhorse of modern JavaScript! The trusty arrow function. The thing that got everyone so excited when ES6 first started shaping up.

So what's the deal? this has historically been one of the trickiest parts of using JavaScript. Because of dynamic scoping you could never quite tell what this would point to in a function. It points to "current scope", which is different than the scope in which you defined your function. To many (most?) this is confusing.

Several more or less elegant ways emerged to deal with the confusion. Using .bind() is perhaps the best approach. But with arrow functions, you don't need any of that. An arrow function is always bound to the scope it's defined in. That means you can pass it around and its this variable will always point the same.

Arrow functions also use cleaner syntax, which makes them nicer to use as iterators. Which just so happens to be the most common reason you need binding.

I am personally both a fan of classes and think they were the wrong step for JavaScript to take. Yes, they make object oriented programming (OOP) a whole lot nicer, which is good, but they also encourage it. I like to use objects as bags-of-methods, and avoid traditional OOP architectures.

That said, classes are useful and ES6 syntax sugar does make them much easier to use. The biggest improvement is to class inheritance.

ES6 gave us a native way to organize our code into modules: import and export. It's a cleaner and more feature-full way of doing require(), which was never part of the official spec anyway.

What I like about modules, is that you can explicitly define what you're taking out of a file. Look at the top of the file and you know exactly what it uses. No more fishing around to find actual use cases.

Another nice feature is that you can give your own names to imported things. This is especially useful when semantic meaning of a function or class differs between modules. It happens more than you'd think.

These code samples don't work in CodePen, so you'll have to take my word for it.

ES2016 added the much needed includes function to arrays. That's not a big update, so I thought I'd show you some helpful Array functions you might not have known existed. Some have been there for a while. All have become more useful with the addition of arrow functions.

I often see people reach for Lodash or similar when they need these primitivies, but there's no need. Unless you have huge performance needs on the scale of millions of operations per second.

Async/await is ES2017's answer to Promises hell. I think. Not sure anyone was complaining about Promises hell, but async/await is a nicer way to use Promises. The so called "synchronous way".

You can tag functions as async and use them as if they were normal functions. To access their future value, you use await. Similar concepts to Promises, but fewer parentheses. Once more you can think of async/await as monads, if that helps.

When it comes to error handling async/await puts us back in the era of throw/catch. Some people like that, some don't, but it's not much different than using .catch.

It doesn't add much to ensuring a set of async functions finishes. You still have to use Promise.all for that.