JSRocksHQ / slush-es20xx

Full ECMAScript.next development and deployment workflow.
Other
6 stars 1 forks source link

Internal refactoring: use ECMAScript 2015? #38

Open UltCombo opened 8 years ago

UltCombo commented 8 years ago

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

jaydson commented 8 years ago

It seems a bit controversial that es20xx enables an excellent ES.next workflow but is itself written in ES5

Agree.

using Promises could add some overhead regarding massive projects

I don't think we'll have something so critical that Promises can turn into a bad guy

es20xx is almost entirely streams

Yeah, perhaps we can keep this and evaluate where is the best scenario to use Promises

UltCombo commented 8 years ago

Thanks for the input. :smile: 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.