Hacker News Reader

Comment by igl | Hacker News Reader

First we have to wait for complete implementations.

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.

View on HN

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

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

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.

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

Reply on news.ycombinator.com