javascript interpreter*
They are only talking about one javascript engine (node). They didn't test any other engine or go into the implementation in node. For all we know, this might just be a poorly optimized code path in node that needs a little love, but the author didn't bother doing any investigation.
Looking at the linked github issue, jsc doesn't have the performance penalty. It would have been interesting if the author had investigated why and shared that with us.
If this article is about hoisting then this is a well-made high-effort high-value article. If this article is about performance then this is a low-effort low-value summary of a github issue they read.
> If this article is about hoisting then this is a well-made high-effort high-value article.
? There is no mention of hoisting in the article, not the name or the concept. I am not even sure the author knows the concept of hoisting and that 'let' and 'var' behave differently. All the examples are suspiciously missing the key differences, and all the surrounding text is about the scope of the if construct.
Maybe it could be optimized more but the TDZ fundamentally adds a performance cost, because it requires a runtime check to see if the variable has been initiatalized yet.
Also node used the v8, the same engine as chromium. So this doesn't just affect node, it also affects the majority of the browser share market. oh, and deno uses v8 too.