FR: Rewrite libs in ES201{5/6}

[hemanth]

It would nice to have lib in ES201{5/6} now that we support few features, did not const being used widely, we could bring in others as well?

[bnoordhuis]

Do you concrete proposals? Please note that some ES6 features have performance issues that currently make them unsuitable for use in core.

[jasnell]

In general, newer ES6 features will eventually begin to creep into lib more and more but only when we're sure they're being optimized by V8 and we're sure they actually make sense. For instance, we do make extensive use of const and we're starting to see more use of template strings. However, things like Promise support in the API isn't likely to happen for a very very long time if at all. As @bnoordhuis suggests, it's better (more effective) to come up with proposals for very specific changes where use of the newer ES features would provide a definitive benefit.

[mikeal]

Perhaps we should add an "ES6" section to the contribution guidelines that details which features are acceptable to use in core (basically the ones that have been optimized).

[jasnell]

that would be helpful... but I would be careful about classifying them as "acceptable". It should be positioned as a best practice based on (1) what is optimized and (2) what is in the best interests of the ecosystem

[rvagg]

Going to close this because:

1. There are performance concerns with many of the new features so they are only being embraced insofar as they can match (or beat, hah!) the performance we have without them
2. The general consensus in core is that pull requests should not create unnecessary churn—this particularly helps when tracking down the cause of a bug because you don't get continually hung up on commits that don't make a difference. This policy for instance means that we are currently in a state of having mixed const and var usage although many collaborators are preferring the former, nobody really wants to see a commit that does a bulk replacement.

[hemanth]

Perhaps we should add an "ES6" section to the contribution guidelines

👍 An ES6 specific experimental branch would be useful?

performance concerns

🌵 Yes, I have seen few cases where the polyfill is faster! [Agree polyfill doesn't take care of all the edge cases, but some of those edge cases are for the 1% ]

nobody really wants to see a commit that does a bulk replacement.

Agree, it could be a slow progression, at least with those with no perf issues?