Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

vincentrolfs.dev

Post reply on HN
Print view View original

21–30 of 64 posts

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

#21

Post by happytoexplain »

taejavu wrote: 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 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.

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

#22

Post by happytoexplain »

throw-the-towel wrote: post #5
taejavu wrote: 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.

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

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

#24

Post by craftkiller »

happytoexplain wrote: post #20
craftkiller wrote: post #3

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

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.

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

#25

Post by jvanderbot »

happytoexplain wrote: post #21
taejavu wrote: 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 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.

In particular if it violates the assumptions of any non native programmer, then it's fair game for gripes.

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

#26

Post by pynappo »

craftkiller wrote: post #15
Aurornis wrote: post #9

Earlier quoted context omitted.

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 rep…

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

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

#27

Post by chatmasta »

sfink wrote: post #11
taejavu wrote: 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.

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, thi…

This is not some terrible decision that comes with only downsides. In fact there are quite a few upsides to the flexibility it brings compared to a language like Python that works as you describe.

It basically means you can always override anything, which allows for monkey patching and proxying and adapter patterns and circular imports… These are all nasty things to accidentally encounter, but they can also be powerful tools when used deliberately.

These hoisting tricks all play an important role in ensuring backwards compatibility. And they’re the reason why JavaScript can have multiple versions of the same package while Python cannot.

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

#28

Post by sjrd »

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.

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

#29

Post by Goofy_Coyote »

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

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

#30

Post by spankalee »

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!

Post reply on HN