It seems a bit controversial that es20xx enables an excellent ES.next workflow but is itself written in ES5.
The main reason for this was performance and keeping its development workflow the simplest possible, but these points do not hold true anymore. Node.js v4 supports quite a few ES2015 features out of the box, and gulp 3.9+ has built-in support for Babel. Or we could even go further and self-host es20xx.
One of my main concerns is that using Promises could add some overhead regarding massive projects, but I'm not sure if this would actually result in an observable perf impact. Another point is that es20xx is almost entirely streams, and virtually all stream packages still use callbacks. This means we would end up spending a lot of effort promisifying those and/or mixing promises and callbacks.
I believe promises may take some experimentation. I'm okay with using the rest of the ES2015 features, though they may not immediately provide a significant benefit.
Thoughts?
cc @jaydson
It seems a bit controversial that es20xx enables an excellent ES.next workflow but is itself written in ES5.
The main reason for this was performance and keeping its development workflow the simplest possible, but these points do not hold true anymore. Node.js v4 supports quite a few ES2015 features out of the box, and gulp 3.9+ has built-in support for Babel. Or we could even go further and self-host es20xx.
One of my main concerns is that using Promises could add some overhead regarding massive projects, but I'm not sure if this would actually result in an observable perf impact. Another point is that es20xx is almost entirely streams, and virtually all stream packages still use callbacks. This means we would end up spending a lot of effort promisifying those and/or mixing promises and callbacks.
I believe promises may take some experimentation. I'm okay with using the rest of the ES2015 features, though they may not immediately provide a significant benefit.
Thoughts?
cc @jaydson