5 ms·

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

119 points by vincentrolfs 1y ago

taejavu 1y ago
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.
- throw-the-towel 1y ago
  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.
  - samus 1y ago
    In most languages, each block indeed is a separate scope. And it avoids foot guns about accidentally using variables that already serve another purpose. I guess it's one of the things that are typical for dynamic languages.
  - Aurornis 1y ago
    > I actually don't understand why do people believe every pair of curly braces has to be its own separate scope. It’s much easier to reason about when your variables aren’t going to escape past the end of the block. In non-GC languages going out of scope can also be a trigger to free the contents of the variable. This is useful for situations like locking where you can put the minimal span of code that requires the lock into a scope and take a lock which automatically unlocks at the end of the scope, for example. JavaScript’s hoisting and scoping feel natural to people who started in JS, but most people who came from other languages find it surprising.
    - mjmas 1y ago
      GCed languages often also have a mechanism for running code on scope exit. For example Lua's <close> attribute, which runs a metamethod when it goes out of scope rather than having to wait for GC: function readfile(name) local f <close> = assert(io.open(name)) return assert(f:read"a") end
  - thaumasiotes 1y ago
    > An explicit construct for scoping would have been so much clearer to me. What would be the advantage over the system used everywhere else?
  - happytoexplain 1y ago
    >I actually don't understand why do people believe every pair of curly braces has to be its own separate scope To avoid having to memorize yet one more thing that doesn't have an obvious benefit. >An explicit construct for scoping would have been so much clearer to me Having an additional construct for scoping is clearer than having every set of already-existing curly braces be a new scope? That seems backwards.
  - deleted 1y ago
    [deleted]
  - 1718627440 1y ago
    > An explicit construct for scoping would have been so much clearer to me. Yes, maybe we could use something similar to parenthesis. Maybe they can look curly. /s
- sfink 1y ago
  That's not how lexical scope works anywhere but in JavaScript. Or rather, it's the interaction between "normal" lexical scope and hoisting. In a "normal" lexically scoped language, if you tried: function f() { return x; // Syntax parsing fails here. } let x = 4; return f(); you would get the equivalent of a ReferenceError for x when f() tried to use it (well, refer to it) at the commented line. But in JavaScript, this successfully returns 4, because `let` inherits the weird hoisting behavior of `var` and `function`. And it has to, because otherwise this would be really weird: function f1() { return x; } let x = 4; function f2() { return x; } return Math.random() < 0.5 ? f1() : f2(); Would that have a 50/50 chance of returning the outer x? Would the engine have to swap which x is referred to in f1 when x gets initialized? TDZ is also terrible because the engines have to look up at runtime whether a lexical variable's binding has been initialized yet. This is one reason (perhaps the main reason?) why they're slower. You can't constant fold even a `const`, because `const v = 7` means at runtime "either 7 or nothing at all, not even null or undefined". In my opinion, TDZ was a mistake. (Not one I could have predicted at the time, so no shade to the designers.) The right thing to do when introducing let/const would have been to make any capture of a lexical variable disable hoisting of the containing function. So the example from the article (trimmed down a little) return Math.random() < 0.5 ? useX() : 1; let x = 4; function useX() { return x; } would raise a ReferenceError for `useX`, because it has not yet been declared at that point in the syntactic scope. Same with the similar return Math.random() < 0.5 ? x : 1; let x = 4; which in current JavaScript also either returns 1 or throws a ReferenceError. I'm not against hoisting functions, and removing function hoisting would have not been possible anyway. The thing is, that's not "just a function", that's a closure that is capturing something that doesn't exist yet. It's binding to something not in its lexical scope, an uninitialized slot in its static environment. That's a weird special case that has to be handled in the engine and considered in user code. It would be better to just disallow it. (And no, I don't think it would be a big deal for engines to detect that case. They already have to compute captures and bindings.) Sadly, it's too late now.
  - deleted 1y ago
    [deleted]
  - taejavu 1y ago
- happytoexplain 1y ago
  I think it's reasonable to have the opinion that the way lexical scoping works in JS is "terrible". You may disagree, but "that's just how it works" isn't a good argument. That line of reasoning is often a rationalization that we make when we are very used to a technology - a sort of hostage situation.
  - jvanderbot 1y ago
    In particular if it violates the assumptions of any non native programmer, then it's fair game for gripes.
- bigstrat2003 1y ago
  I mean, it certainly is surprising to me that you can use the variables before they are declared (albeit with undefined values).
craftkiller 1y ago
This is just javascript variable hoisting: https://developer.mozilla.org/en-US/docs/Glossary/Hoisting https://developer.mozilla.org/en-US/docs/Glossary/Hoisting
- Aurornis 1y ago
  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.
  - craftkiller 1y ago
    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.
    - wonnage 1y ago
      Yes it turns out the article’s conclusion is in fact contained in the conclusion paragraph
      - dwattttt 1y ago
        To be fair, with JS's initialisation rules it does feel like it could have been anywhere.
    - pynappo 1y ago
      > 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?
adzm 1y ago
Considering anything that transpiled to ES5 would have to use var anyway, I'm curious why this was done in the source itself and not as a plugin/build step.
- inbx0 1y ago
  The post links to a TS issue [1] that explains > As of TypeScript 5.0, the project's output target was switched from es5 to es2018 as part of a transition to ECMAScript modules. This meant that TypeScript could rely on the emit for native (and often more-succinct) syntax supported between ES2015 and ES2018. One might expect that this would unconditionally make things faster, but surprise we encountered was a slowdown from using let and const natively! So they don't transpile to ES5, and that is the issue. 1: https://github.com/microsoft/TypeScript/issues/52924 https://github.com/microsoft/TypeScript/issues/52924
benatkin 1y ago
To me it isn't unlike react having onChange={<function to be called when the input event fires>} I can always rely on FAANGs to make things unnecessarily confusing and ugly.
- sorrythanks 1y ago
  i don't understand the connection
  - deleted 1y ago
    [deleted]
sjrd 1y ago
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.
- csto12 1y ago
  I wonder how many companies are still using Scala.js. Scala was fun to work with, wish it was more popular these days.
  - sjrd 1y ago
    Usage of Scala.js is steadily growing. Several indicators suggest that 1 in 5 Scala developers use Scala.js at this point. It's regularly brought up as one of the strongest suits of Scala. Usage of Scala itself is less shiny if you look at market share. But I believe it's still growing in absolute numbers, only quite slowly.
    - coldtea 1y ago
      >Usage of Scala.js is steadily growing. Several indicators suggest that 1 in 5 Scala developers use Scala.js at this point. Wow! 4 out of 20 total ain't bad! Jocking aside the starting set (Scala developers) is already small, so it's not like either it or even less Scala.js is going to be a major player anytime soon.
- onion2k 1y ago
  `let`s and `const`s incur a significant performance penalty. Is that still true? Early versions of V8 would do scope checks for things that weren't declared with var but it doesn't do that any more. I think const and let are lowered to var representation at compile time now anyway, so when the code is running they're the same thing.
  - sjrd 1y ago
Goofy_Coyote 1y ago
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 <snip> 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 way of saying “I have no idea what this thing is”. So where’s the leakage?
- Jtsummers 1y ago
  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 <snip> 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.
  - Goofy_Coyote 1y ago
    Thanks for the tip, and also thanks for the explanation. I understand what’s going on here now. Much appreciated
spankalee 1y ago
I've tried to get V8 at least to implement smarter TDZ elision for a long time, which would eliminate the need for these shenanigans. There are some relatively simple heuristics where you can tell without escape analysis that a variable will not be referenced before initialization. The obviously bad constructions are references in the same scope that happen before the declaration. It'd be nice if these were an early errors, but alas, so keep the TDZ check. The next is any closed over reference that happens before the initializer. These may run before the initializer, so keep the TDZ check. Then you have hoisted closures even if they're after the initializer (eg, var and function keyword declarations). These might run before the initializer too. But everything else that comes after the initializer: access in the same or nested scope and access in closures in non-hoisted declarations, can't possibly run before the initializer and doesn't need the TDZ check. I believe this check is cheap enough to run during parsing. The reason for not pursuing it was that there wasn't a benchmark that showed TDZ checks were a problem. But TypeScript showed they were!
- syg 1y ago
  This kind of elision is implemented.
twistedpair 1y ago
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.
conartist6 1y ago
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.
- pverheggen 1y ago
  I think it’ll still throw a ReferenceError. Initialization is optional, but you still have to initialize before referencing.
  - rictic 1y ago
    Nope. `(() => {let bar; return bar})()` is `undefined`
    - deleted 1y ago
      [deleted]
- strken 1y ago
  The article is slightly wrong. The TDZ is the zone before the variable is declared, not after. Referencing variables before they're declared isn't valid for `let` and hence it needs a TDZ check. Consider console.log(foo) let foo vs console.log(foo) var foo I think the article confuses "in scope" with "declared", and "declared and initialised" with "initialised".
pwdisswordfishy 1y ago
I wish they had made lexical scope work like Lua, where the binding simply does not exist before the declaration – including in the initialization expression: local x = 42 do print(x) -- 42 local x = x * 2 print(x) -- 84 end print(x) -- 42 Look, ma! No dead zones!

119 points by vincentrolfs 1y ago

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.

throw-the-towel 1y ago
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.
- samus 1y ago
  In most languages, each block indeed is a separate scope. And it avoids foot guns about accidentally using variables that already serve another purpose. I guess it's one of the things that are typical for dynamic languages.
- Aurornis 1y ago
  > I actually don't understand why do people believe every pair of curly braces has to be its own separate scope. It’s much easier to reason about when your variables aren’t going to escape past the end of the block. In non-GC languages going out of scope can also be a trigger to free the contents of the variable. This is useful for situations like locking where you can put the minimal span of code that requires the lock into a scope and take a lock which automatically unlocks at the end of the scope, for example. JavaScript’s hoisting and scoping feel natural to people who started in JS, but most people who came from other languages find it surprising.
  - mjmas 1y ago
    GCed languages often also have a mechanism for running code on scope exit. For example Lua's <close> attribute, which runs a metamethod when it goes out of scope rather than having to wait for GC: function readfile(name) local f <close> = assert(io.open(name)) return assert(f:read"a") end
- thaumasiotes 1y ago
  > An explicit construct for scoping would have been so much clearer to me. What would be the advantage over the system used everywhere else?
- happytoexplain 1y ago
  >I actually don't understand why do people believe every pair of curly braces has to be its own separate scope To avoid having to memorize yet one more thing that doesn't have an obvious benefit. >An explicit construct for scoping would have been so much clearer to me Having an additional construct for scoping is clearer than having every set of already-existing curly braces be a new scope? That seems backwards.
- deleted 1y ago
  [deleted]
- 1718627440 1y ago
  > An explicit construct for scoping would have been so much clearer to me. Yes, maybe we could use something similar to parenthesis. Maybe they can look curly. /s
sfink 1y ago
That's not how lexical scope works anywhere but in JavaScript. Or rather, it's the interaction between "normal" lexical scope and hoisting. In a "normal" lexically scoped language, if you tried: function f() { return x; // Syntax parsing fails here. } let x = 4; return f(); you would get the equivalent of a ReferenceError for x when f() tried to use it (well, refer to it) at the commented line. But in JavaScript, this successfully returns 4, because `let` inherits the weird hoisting behavior of `var` and `function`. And it has to, because otherwise this would be really weird: function f1() { return x; } let x = 4; function f2() { return x; } return Math.random() < 0.5 ? f1() : f2(); Would that have a 50/50 chance of returning the outer x? Would the engine have to swap which x is referred to in f1 when x gets initialized? TDZ is also terrible because the engines have to look up at runtime whether a lexical variable's binding has been initialized yet. This is one reason (perhaps the main reason?) why they're slower. You can't constant fold even a `const`, because `const v = 7` means at runtime "either 7 or nothing at all, not even null or undefined". In my opinion, TDZ was a mistake. (Not one I could have predicted at the time, so no shade to the designers.) The right thing to do when introducing let/const would have been to make any capture of a lexical variable disable hoisting of the containing function. So the example from the article (trimmed down a little) return Math.random() < 0.5 ? useX() : 1; let x = 4; function useX() { return x; } would raise a ReferenceError for `useX`, because it has not yet been declared at that point in the syntactic scope. Same with the similar return Math.random() < 0.5 ? x : 1; let x = 4; which in current JavaScript also either returns 1 or throws a ReferenceError. I'm not against hoisting functions, and removing function hoisting would have not been possible anyway. The thing is, that's not "just a function", that's a closure that is capturing something that doesn't exist yet. It's binding to something not in its lexical scope, an uninitialized slot in its static environment. That's a weird special case that has to be handled in the engine and considered in user code. It would be better to just disallow it. (And no, I don't think it would be a big deal for engines to detect that case. They already have to compute captures and bindings.) Sadly, it's too late now.
- deleted 1y ago
  [deleted]
- taejavu 1y ago
happytoexplain 1y ago
I think it's reasonable to have the opinion that the way lexical scoping works in JS is "terrible". You may disagree, but "that's just how it works" isn't a good argument. That line of reasoning is often a rationalization that we make when we are very used to a technology - a sort of hostage situation.
- jvanderbot 1y ago
  In particular if it violates the assumptions of any non native programmer, then it's fair game for gripes.
bigstrat2003 1y ago
I mean, it certainly is surprising to me that you can use the variables before they are declared (albeit with undefined values).

craftkiller 1y ago

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

Aurornis 1y ago
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.
- craftkiller 1y ago
  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.
  - wonnage 1y ago
    Yes it turns out the article’s conclusion is in fact contained in the conclusion paragraph
    - dwattttt 1y ago
      To be fair, with JS's initialisation rules it does feel like it could have been anywhere.
  - pynappo 1y ago
    > 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?

adzm 1y ago

Considering anything that transpiled to ES5 would have to use var anyway, I'm curious why this was done in the source itself and not as a plugin/build step.

inbx0 1y ago
The post links to a TS issue [1] that explains > As of TypeScript 5.0, the project's output target was switched from es5 to es2018 as part of a transition to ECMAScript modules. This meant that TypeScript could rely on the emit for native (and often more-succinct) syntax supported between ES2015 and ES2018. One might expect that this would unconditionally make things faster, but surprise we encountered was a slowdown from using let and const natively! So they don't transpile to ES5, and that is the issue. 1: https://github.com/microsoft/TypeScript/issues/52924 https://github.com/microsoft/TypeScript/issues/52924

benatkin 1y ago

To me it isn't unlike react having onChange={<function to be called when the input event fires>} I can always rely on FAANGs to make things unnecessarily confusing and ugly.

sorrythanks 1y ago
i don't understand the connection
- deleted 1y ago
  [deleted]

sjrd 1y ago

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.

csto12 1y ago
I wonder how many companies are still using Scala.js. Scala was fun to work with, wish it was more popular these days.
- sjrd 1y ago
  Usage of Scala.js is steadily growing. Several indicators suggest that 1 in 5 Scala developers use Scala.js at this point. It's regularly brought up as one of the strongest suits of Scala. Usage of Scala itself is less shiny if you look at market share. But I believe it's still growing in absolute numbers, only quite slowly.
  - coldtea 1y ago
    >Usage of Scala.js is steadily growing. Several indicators suggest that 1 in 5 Scala developers use Scala.js at this point. Wow! 4 out of 20 total ain't bad! Jocking aside the starting set (Scala developers) is already small, so it's not like either it or even less Scala.js is going to be a major player anytime soon.
onion2k 1y ago
`let`s and `const`s incur a significant performance penalty. Is that still true? Early versions of V8 would do scope checks for things that weren't declared with var but it doesn't do that any more. I think const and let are lowered to var representation at compile time now anyway, so when the code is running they're the same thing.
- sjrd 1y ago

Goofy_Coyote 1y ago

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 <snip> 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 way of saying “I have no idea what this thing is”. So where’s the leakage?

Jtsummers 1y ago
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 <snip> 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.
- Goofy_Coyote 1y ago
  Thanks for the tip, and also thanks for the explanation. I understand what’s going on here now. Much appreciated

spankalee 1y ago

I've tried to get V8 at least to implement smarter TDZ elision for a long time, which would eliminate the need for these shenanigans. There are some relatively simple heuristics where you can tell without escape analysis that a variable will not be referenced before initialization. The obviously bad constructions are references in the same scope that happen before the declaration. It'd be nice if these were an early errors, but alas, so keep the TDZ check. The next is any closed over reference that happens before the initializer. These may run before the initializer, so keep the TDZ check. Then you have hoisted closures even if they're after the initializer (eg, var and function keyword declarations). These might run before the initializer too. But everything else that comes after the initializer: access in the same or nested scope and access in closures in non-hoisted declarations, can't possibly run before the initializer and doesn't need the TDZ check. I believe this check is cheap enough to run during parsing. The reason for not pursuing it was that there wasn't a benchmark that showed TDZ checks were a problem. But TypeScript showed they were!

syg 1y ago
This kind of elision is implemented.

twistedpair 1y ago

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.

conartist6 1y ago

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.

pverheggen 1y ago
I think it’ll still throw a ReferenceError. Initialization is optional, but you still have to initialize before referencing.
- rictic 1y ago
  Nope. `(() => {let bar; return bar})()` is `undefined`
  - deleted 1y ago
    [deleted]
strken 1y ago
The article is slightly wrong. The TDZ is the zone before the variable is declared, not after. Referencing variables before they're declared isn't valid for `let` and hence it needs a TDZ check. Consider console.log(foo) let foo vs console.log(foo) var foo I think the article confuses "in scope" with "declared", and "declared and initialised" with "initialised".

pwdisswordfishy 1y ago

I wish they had made lexical scope work like Lua, where the binding simply does not exist before the declaration – including in the initialization expression: local x = 42 do print(x) -- 42 local x = x * 2 print(x) -- 84 end print(x) -- 42 Look, ma! No dead zones!