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
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.
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).
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
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
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.
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?
Activity
bnoordhuis commentedon Oct 14, 2015
Do you concrete proposals? Please note that some ES6 features have performance issues that currently make them unsuitable for use in core.
jasnell commentedon Oct 14, 2015
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
constand 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 commentedon Oct 14, 2015
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 commentedon Oct 14, 2015
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 commentedon Oct 15, 2015
Going to close this because:
constandvarusage although many collaborators are preferring the former, nobody really wants to see a commit that does a bulk replacement.hemanth commentedon Oct 15, 2015
👍 An
ES6specific experimental branch would be useful?🌵 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% ]
Agree, it could be a slow progression, at least with those with no perf issues?