ECMAScript 6: new OOP features besides classes

We don't have to wait to use these features, we can use them today with Traceur, 6to5, ES6ify, etc.

You are absolutely right when it comes to using ECMAScript 6 natively. It will officially become a standard in mid 2015. By then modern browsers should have implemented most of it, but it will be years until legacy browsers go away. It feels to me that (for most projects) we can just now rely on ECMAScript 5 being there everywhere.

On the other hand, there are already a few decent solutions for transpiling ECMAScript 6 to ES5 [1]:

* Traceur (there are Traceur-based plugins for Grunt, Gulp, browserify, webpack, etc.): https://github.com/google/traceur-compiler

* 6to5: https://6to5.org/

* es6-transpiler.js: https://github.com/termi/es6-transpiler

Using those tools results in a workflow that is much like using CoffeeScript.

[1] http://www.2ality.com/2014/08/es6-today.html

Having a standard for classes would be significant even if no browser implemented it.

Nearly every JavaScript ecosystem has a class pattern. Ember, Angular, YUI, React, MooTools etc. All of them are incompatible.

A spec gives us a common target to iterate toward, even if we need to get there via transpilers. Just like standardizing on Promises means I can consume jQuery's ajax method without learning a new callback syntax, ES6 classes will mean I don't need to learn a new API for extending a parent class in every framework.

The Ember community has had amazing success adopting ES6 modules despite there being no browser support at all. I expect any framework would have a similar success story with classes.

>generators, async keyword these should be prioritized not class based inheritance

Generators are indeed being prioritized over classes and inheritance; the former is starting to see support in browsers but there's no sign of the latter.

The async-await keywords are not in ES6, but they are trivial to mimic with generators and promises if you so desire.

>Even block scoping I mean maybe I'm nuts but function scoping if you take the time to understand it, it works.

Block scoping introduces no new pitfalls (unless you count learning two new keywords a pitfall). It does however eliminate two classes of bugs - redeclaring a var with the intent of shadowing the previous one but actually overwriting it, and using a var outside of a scope where it has a legal value. I'd say it's worth it.

Javascript books get bigger, "The Good Parts" stays the same.

you want everything to be local. local should be the default. Thou shalt not be implicitly global.

I think let is supposed to replace var completely. There's a brief mention of this in a book I was reading the other day (Understanding ES6: https://leanpub.com/understandinges6/read/ ) but no citation of where that decision comes from.

> Are you supposed to only use let now?

Yes, if you can use `let`, there is no reason whatsoever to use `var` ever again.

If you want the `var` behavior, just put your declaration at the very top of the innermost function. With most code conventions, that's where you'd put a `var` declaration anyways.

For what it's worth, Crockford also recommended to use `let` exclusively as soon as you can.

I'm using a lot of them in production right now, thanks to transpilers. Unfortunately not everything can work without the aid of a run-time, which is how Traceur works. At the moment i'm limiting myself to the features that don't require such a run-time.

18 months - 2 years would be an appropriate time to use ES6 features safely without a transpiler (however we will still be using transpilers in the future for ES7 and ES8). But you can use them today using a transpiler like 6to5 or Traceur.

Ironically: http://ckknight.github.io/gorillascript/

Just include everything possible in the language. What could go wrong?

Although we already have C++.

I find funny what you find "mind blowing".