Today we’ve reached an important milestone: V8 supports ES6 and ES7 . You can use the new language features today in Chrome Canary, and they will ship by default in the M52 release of Chromium.
An evolving spec
|Currently shipping parts of the evolving ECMAScript specification|
The continual refinement of the language specification and the fact that each version (including the yet-to-be-ratified draft) replaces, amends, and clarifies previous versions makes it tricky to understand the complexities behind ES6 and ES7 support. While it’s impossible to state succinctly, it’s perhaps most accurate to say that V8 supports compliance with the “continually maintained draft future ECMAScript standard” !
Since it’s difficult to skim the enormous number of test262 tests, other conformance tests exist, such as the Kangax compatibility table . The Kangax table has only enough tests to determine the existence of major language features. This makes it easy to skim to see whether a particular feature (like arrow functions ) has been implemented in a given engine, but doesn’t test all the conformance edge cases that test262 does. Currently, Chrome Canary scores a 98% on the Kangax table for ES6 and 100% on the sections of Kangax corresponding to ES7 (e.g. the sections labelled “2016 features” and “2016 misc” under the ESnext tab).
The remaining 2% of the Kangax ES6 table tests proper tail calls
Proper Tail Calls
Proper tail calls have been implemented but not yet shipped given that a change to the feature is currently under discussion at TC39 . ES6 specifies that strict mode function calls in tail position should never cause a stack overflow. While this is a useful guarantee for certain programming patterns, the current semantics have two problems. First, since the tail call elimination is implicit, it can be difficult for programmers to identify which functions are actually in tail call position. This means that developers may not discover misplaced attempted tail calls in their programs until they overflow the stack. Second, implementing proper tail calls requires eliding tail call stack frames from the stack, which loses information about execution flow. This in turn has two consequences:
- It makes it more difficult to understand during debugging how execution arrived at a certain point since the stack contains discontinuities and
- Error.prototype.stack contains less information about execution flow which may break telemetry software that collects and analyzes client-side errors.
Implementing a shadow stack can improve the readability of call stacks, but the V8 and DevTools teams believe that debugging is easiest, most reliable, and most accurate when the stack displayed during debugging is completely deterministic and always matches the true state of the actual virtual machine stack. Moreover, a shadow stack is too expensive performance-wise to turn on all the time.
For these reasons, the V8 team, along with TC39 committee members from Mozilla and Microsoft, strongly support denoting proper tail calls by special syntax. There is a pending TC39 proposal called syntactic tail calls to specify this behavior. We have implemented and staged proper tail calls as specified in ES6 and started implementing syntactic tail calls as specified in the new proposal. The V8 team plans to resolve the issue at the next TC39 meeting before shipping implicit proper tail calls or syntactic tail calls by default. You can test out each version in the meantime by using the V8 flags –harmony-tailcalls and –harmony-explicit-tailcalls .
ESnext and beyond
In the future, developers can expect ECMAScript updates to come in smaller, more frequent updates with shorter implementation cycles. The V8 team is already working to bring upcoming features such as async / await keywords, Object.prototype.values() / Object.prototype.entries() , String.prototype.padStart() / String.prototype.padEnd() andRegExp lookbehind to the runtime. Check back for more updates on our ESnext implementation progress and performance optimizations for existing ES6 and ES7 features.
— Posted by the V8 team, ECMAScript Enthusiasts