Live data from Hacker News

An update on strong mode

groups.google.com

1–10 of 22 posts

Re: An update on strong mode

#3
> ES6 performance sucks! Strong mode is a mode for ES6, you cannot use it without using various ES6 features. However, idiomatic ES6 code currently is substantially slower than ES5, across all browsers -- easily by 2x, often by 10x or more. Due to the sheer size of ES6, plus a number of unfortunate design choices, it will likely take years until implementations catch up with ES5 optimisations, and the hundreds of man years that went into those.

This has been my suspicion for a while. Perhaps I've missed other comments to this effect, but I don't think I've heard anyone else articulate it.

Re: An update on strong mode

#4
post #3

> ES6 performance sucks! Strong mode is a mode for ES6, you cannot use it without using various ES6 features. However, idiomatic ES6 code currently is substantially slower than ES5, across all browsers -- easily by 2x, often by 10x or more. Due to the sheer size of ES6, plus a number of unfortunate design choices, it will likely take years until implementations catch up with ES5 optimisations, and the hundreds of man…

I wonder which features are slow. I'm assuming generators and by extension the for-of syntax, which is otherwise a thing of beauty. I imagine proxies are somewhere between slow and horrifyingly slow.

I have noticed that none of the features I'd hoped would save cycles (const, generators, fat arrow functions) seem to be helping at all in the browsers of today.

Re: An update on strong mode

#5
For those who were wondering what strong mode is, this is a post to the Strengthening JS group, which for discussion of "strong mode and type system extensions that the V8 team is working on."

Strong mode is "a new language mode (an extension of strict mode) that implements a stronger semantics by removing brittle or costly features."

https://developers.google.com/v8/experiments

The conclusion is that "we have reluctantly decided not to pursue strong mode further."

Re: An update on strong mode

#6
post #3

> ES6 performance sucks! Strong mode is a mode for ES6, you cannot use it without using various ES6 features. However, idiomatic ES6 code currently is substantially slower than ES5, across all browsers -- easily by 2x, often by 10x or more. Due to the sheer size of ES6, plus a number of unfortunate design choices, it will likely take years until implementations catch up with ES5 optimisations, and the hundreds of man…

I wonder which features are slow. I'm assuming generators and by extension the for-of syntax, which is otherwise a thing of beauty. I imagine proxies are somewhere between slow and horrifyingly slow. I have noticed that none of the features I'd hoped would save cycles (const, generators, fat arrow functions) seem to be helping at all in the browsers of today.

Last time I checked, fat arrow functions have a performance penalty because of all the optimisations that's made around scope in regular ES5 functions can't be used.

I believe ES6 fat arrow functions are slow for a similar reasons as why regular functions are slow when you use the magic arguments variable.

Re: An update on strong mode

#7
post #3

> ES6 performance sucks! Strong mode is a mode for ES6, you cannot use it without using various ES6 features. However, idiomatic ES6 code currently is substantially slower than ES5, across all browsers -- easily by 2x, often by 10x or more. Due to the sheer size of ES6, plus a number of unfortunate design choices, it will likely take years until implementations catch up with ES5 optimisations, and the hundreds of man…

I wonder which features are slow. I'm assuming generators and by extension the for-of syntax, which is otherwise a thing of beauty. I imagine proxies are somewhere between slow and horrifyingly slow. I have noticed that none of the features I'd hoped would save cycles (const, generators, fat arrow functions) seem to be helping at all in the browsers of today.

I wouldn't be surprised if const and arrow functions actually make things slower. const, or at least a naive implementation of it, requires checking if the value is changed which var does not. Perhaps that could be equally performant in time.

Arrow functions seem like they would take (marginally) longer to parse than explicit function declarations due to having a more verbose AST that does not start with unambiguous tokens. That, and you have the implicit this binding which must come with a cost. Again, in time this might be okay.

Re: An update on strong mode

#9
post #7

Earlier quoted context omitted.

I wonder which features are slow. I'm assuming generators and by extension the for-of syntax, which is otherwise a thing of beauty. I imagine proxies are somewhere between slow and horrifyingly slow. I have noticed that none of the features I'd hoped would save cycles (const, generators, fat arrow functions) seem to be helping at all in the browsers of today.

I wouldn't be surprised if const and arrow functions actually make things slower. const , or at least a naive implementation of it, requires checking if the value is changed which var does not. Perhaps that could be equally performant in time. Arrow functions seem like they would take (marginally) longer to parse than explicit function declarations due to having a more verbose AST that does not start with unambiguous…

Wouldn't const be checked at compile time?

Re: An update on strong mode

#10
post #2

Why does one of the comments on that thread say strong mode is dead? Everyone seemed to ignore the comment.

Because it _is_ dead. Relevant excerpt from the OP:

TAKE-AWAY

Considering all that, we have reluctantly decided not to pursue strong mode further. We learned some worthwhile lessons, but overall it is not clear that the benefits justify the costs. Starting with the next version of V8, we will hence remove support for strong mode.

Post reply on HN