Live data from Hacker News

The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

vincentrolfs.dev

31–40 of 64 posts

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#31

Need some help understanding what’s going on here. In function example(measurement) { console.log(calculation); // undefined - accessible! calculation leaked out console.log(i); // undefined - accessible! i leaked out Why does the author say `calculation` and `i` are leaking? They’re not even defined at that point (they come later in the code), and we’re seeing “undefined” which, correct me if I’m wrong, is the JS wa…

Two spaces before each line in the code block. HN doesn't use markdown, it's easy to do even on mobile, a demonstration:

  function example(measurement) {
    console.log(calculation); // undefined - accessible! calculation leaked out
    console.log(i); // undefined - accessible! i leaked out 
It's "leaking" because the variable is in scope, it's associated value is "undefined". This is different than with let/const where the variable would not be in scope at that point in the function. An undefined value bound to a variable is not the same as "I have no idea what this thing is". That would be the reference errors seen with let/const.

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#32
post #2

The first example is not “terrible”, that’s just how lexical scope works. I don’t really see the point of complaining about language features like this - either learn how it works or ignore at your peril.

I mean, it certainly is surprising to me that you can use the variables before they are declared (albeit with undefined values).

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#33

Need some help understanding what’s going on here. In function example(measurement) { console.log(calculation); // undefined - accessible! calculation leaked out console.log(i); // undefined - accessible! i leaked out Why does the author say `calculation` and `i` are leaking? They’re not even defined at that point (they come later in the code), and we’re seeing “undefined” which, correct me if I’m wrong, is the JS wa…

Two spaces before each line in the code block. HN doesn't use markdown, it's easy to do even on mobile, a demonstration: function example(measurement) { console.log(calculation); // undefined - accessible! calculation leaked out console.log(i); // undefined - accessible! i leaked out It's "leaking" because the variable is in scope, it's associated value is "undefined". This is different than with let/const where the…

Thanks for the tip, and also thanks for the explanation. I understand what’s going on here now. Much appreciated

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#34
post #2

The first example is not “terrible”, that’s just how lexical scope works. I don’t really see the point of complaining about language features like this - either learn how it works or ignore at your peril.

I second that, I actually don't understand why do people believe every pair of curly braces has to be its own separate scope. An explicit construct for scoping would have been so much clearer to me.

[deleted]

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#35

Earlier quoted context omitted.

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.

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#36

Earlier quoted context omitted.

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.

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#37
It feels like the root of the issue is the scoping design of JS itself, which makes tracking TDZ more costly for the interpreter, and the fact that JS is JIT rather than AOT compiled.

I laud the recent efforts to remove the JS from JS tools (Go in TS compiler, esbuild, etc), as you don't need 100% of your lang utils written in the same interpreted lang, especially slow/expensive tasks like compilation.

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#39

Why wouldn't `let` be exactly what you want? It's block scoped but doesn't need fancy TDZ checks because like `var` it just starts out as undefined.

I think it’ll still throw a ReferenceError. Initialization is optional, but you still have to initialize before referencing.

Re: The Temporal Dead Zone, or why the TypeScript codebase is full of var statements

#40
post #28

Indeed, `let`s and `const`s incur a significant performance penalty. This is also why the Scala.js compiler emits `var`s by default, even when targeting very recent versions of ECMAScript. The good news is that we can still write our Scala `val`s and `var`s (`const` and `let`) in the source code, enjoying good scoping and good performance.

I wonder how many companies are still using Scala.js. Scala was fun to work with, wish it was more popular these days.
Post reply on HN