Live data from Hacker News

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

vincentrolfs.dev

1–10 of 64 posts

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

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

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

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

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.

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

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

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.

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

#8
post #4

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.

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

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

#9

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.

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

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

> An explicit construct for scoping would have been so much clearer to me.

What would be the advantage over the system used everywhere else?

Post reply on HN