3 ms·

First we have to wait for complete implementations. Then wait for v8 performance: http://jsperf.com/performance-frozen-object http://jsperf.com/performance-fro

by igl 12y ago

First we have to wait for complete implementations. Then wait for v8 performance: http://jsperf.com/performance-frozen-object 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.

zghst 12y ago
We don't have to wait to use these features, we can use them today with Traceur, 6to5, ES6ify, etc.
rauschma 12y ago
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 https://github.com/google/traceur-compiler * 6to5: https://6to5.org/ https://6to5.org/ * es6-transpiler.js: https://github.com/termi/es6-transpiler 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 http://www.2ality.com/2014/08/es6-today.html
- igl 12y ago
  I am mostly looking forward to Proxies and Tail calls, both cannot be implemented with traceur :/
mixonic 12y ago
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.
- wildpeaks 12y ago
  Standardizing is also the reason behind ES7 Observable as was explained in this talk (https://www.youtube.com/watch?v=DqMFX91ToLw 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.

by igl 12y ago

zghst 12y ago

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

rauschma 12y ago

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 https://github.com/google/traceur-compiler * 6to5: https://6to5.org/ https://6to5.org/ * es6-transpiler.js: https://github.com/termi/es6-transpiler 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 http://www.2ality.com/2014/08/es6-today.html

igl 12y ago
I am mostly looking forward to Proxies and Tail calls, both cannot be implemented with traceur :/

mixonic 12y ago

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.

wildpeaks 12y ago
Standardizing is also the reason behind ES7 Observable as was explained in this talk (https://www.youtube.com/watch?v=DqMFX91ToLw 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.