Hacker News Reader

Comment by craftkiller | Hacker News Reader

This is just javascript variable hoisting: https://developer.mozilla.org/en-US/docs/Glossary/Hoisting

No, the crux of the article is that using var instead of let or const can produce a performance improvement by reducing the complexity of what the interpreter must track.

They cite a surprising 8% performance boost in some cases by using var.

By crux you mean the 1 paragraph at the end where it mentions performance? That's basically a footnote to an article that spends the other 99% describing javascript variable hoisting. They cite an 8% performance boost but they don't analyze it, instead just claiming it is a lot of work for the interpreter and linking to a github issue. They've run no benchmarks. They have shown no interpreter internals. They just report that one project saw an 8% performance improvement.

They did a great job of explaining javascript variable hoisting, but that's all that they have explained.

Yes it turns out the article’s conclusion is in fact contained in the conclusion paragraph

To be fair, with JS's initialisation rules it does feel like it could have been anywhere.

> By crux you mean the 1 paragraph at the end where it mentions performance? That's basically a footnote to an article that spends the other 99% describing javascript variable hoisting.

Isn't that part still the crux of the article as it contains the answer to the title?

Yes. But what are you implying by the word "just"? It sounds like you're saying we should be taking something different away from the article's description of this behavior simply because you have put a name to it.

Think of it like a tl;dr. Hoisting is common knowledge to javascript programmers, so I've managed to compress the information of this article into 6 words for them.

The interesting part here is that javascript interpreters not having to track the TDZ comes with an interesting performance bonus.

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.

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.

> 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.

Reply on news.ycombinator.com