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]:
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.
Standardizing is also the reason behind ES7 Observable as was explained in this talk (https://www.youtube.com/watch?v=DqMFX91ToLw) from Jafar Husain (Netflix & ES7 committee) which explains very well ES6/ES7 features like iterators, promises, generators, async functions and async generators.
I'm sorry most of the sugar I don't find particularly helpful and can be confusing when you have more than one way to do something. generators, async keyword these should be prioritized not class based inheritance. Even block scoping I mean maybe I'm nuts but function scoping if you take the time to understand it, it works.
>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.
I'd say fat-arrow lambdas and multiple variable assignments are good... a lot of the other stuff, don't care as much... though generators/promises leading to await/async is pretty good too.
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 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.
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.
Then why not use something like https://6to5.org/ ? Most syntax features can be transpiled without a runtime (generators being an exception) and everything else can simply use polyfills.
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.
Being able to (eventually) use all these language features in a language that's running inside a browser is blowing my mind right now. It's got iterators! It's got properties!
Then wait for v8 performance: http://jsperf.com/performance-frozen-object ES5 is doing good...
And at last: Wait for < IE-11 to die.
It remains to be seen if io.js will boosts ES Next for the server. Since bound to v8 i don't expect much.
Other implementations like the ahead of time compiler echojs become interesting. I am also curious how Typescript will look at v2.0.
I am ready, however I still don't use arrow functions... Which were first heard of in 2010? 2011?
It still feels like so far away.