[venning]

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.

[dangoor]

Wouldn't const be checked at compile time?

[venning]

That's still a check that var is not subject to. Hence, it's a little slower (in theory).

[phpnode]

In theory, the opposite, because a compiler knows that a constant binding never changes so the value it references can be inlined everywhere it is used without having to do runtime checks. But I think engines are not doing this yet.

[venning]

I haven't written enough ES6 to answer this for myself, but doesn't the dynamic nature of the language mean that constants can be at risk of invalid LHS operations at run-time? (At least, those positioned high enough in the scope to be subject to the necessary operations, which could be a lot.) I'm thinking of eval specifically, but perhaps there are other ways of doing this.

[david-given]

I think if you use eval, all bets are off anyway.

But I think that in ES6 without eval you can't refer to the current scope in a dynamic way; which means that the engine can resolve bindings at compile time without worrying about people fiddling with scopes behind the scenes, which should simplify optimisation a lot.