You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Thanks for the input. 😄
Let's hold off the refactoring until v3.0.0 is released, then we can break this package into small modules and refactor them to use the new features.
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
The text was updated successfully, but these errors were encountered: