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!
local x = 42
do
print(x) -- 42
local x = x * 2
print(x) -- 84
end
print(x) -- 42
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.
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.
In
function example(measurement) {
console.log(calculation); // undefined - accessible! calculation leaked out
console.log(i); // undefined - accessible! i leaked out
<snip>
I can always rely on FAANGs to make things unnecessarily confusing and ugly.
> 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.
Consider
console.log(foo)
let foo
console.log(foo)
var foo
function f() {
return x; // Syntax parsing fails here.
}
let x = 4;
return f();
function f1() { return x; }
let x = 4;
function f2() { return x; }
return Math.random() < 0.5 ? f1() : f2();
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; }
return Math.random() < 0.5 ? x : 1;
let x = 4;
Sadly, it's too late now.
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.
They cite a surprising 8% performance boost in some cases by using var.
function example(measurement) {
console.log(calculation); // undefined - accessible! calculation leaked out
console.log(i); // undefined - accessible! i leaked out <snip>
I wish there was explicit support for this though, maybe with a construct like <exression> where <antecedent>, etc, like what Haskell has, instead of having to hack it using functions and var
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.
function f() {
return g()
}
function g() {
return f()
}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.
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.
They did a great job of explaining javascript variable hoisting, but that's all that they have explained.
Yes, maybe we could use something similar to parenthesis. Maybe they can look curly. /s
What would be the advantage over the system used everywhere else?
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.
My solution would only stop hoisting closures that capture lexicals, with the idea that capturing a lexical means that the closure's identity is now tied to that lexical environment anyway so it's kind of bizarre to hoist it out to where part of its identity is missing.
But you were giving a simplified example, so I want to be sure I'm not dismissing your concern unfairly. This would not work:
function f() {
return g(); // ReferenceError
}
let x = 4;
function g() {
return x + f();
}
let x = 4;
function f() {
return x + g(); // ReferenceError? Unfortunate if so...
}
function g() {
return x - f();
}
let x = f(); // ReferenceError
let y = 2;
function f() {
return y;
}
let x = 4;
let function f() {
return x + g();
}
let function g() {
return x - f();
}
I was really using your comment as a jumping off point for my rant.
I wouldn't describe `var` declarations as lexical, though. Sure, they have a lexical scope that they get hoisted up to cover, but hoisting is not "just lexical scope". It's unusual.
There isn't a difference between lexical scope and "block" scope. What I think you are referring to as "block" scope, is a subset of lexical scope. The difference between var and let/const is where the boundaries of the lexical scope is.
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.
There are several examples in the blog, and only one is the first. It does not include the "terrible" descriptor after it. So your comment is kind of odd because it doesn't connect to the article at all.
If you mean the first example that's described as "terrible", that's the second example and it's the one with the leaking loop variable. It kind of is terrible, Python has the same problem (and many others, Python scoping rules are not good). C used to have that problem but they at least had the good sense to fix it.
local b
local function a()
return b()
end
b = function()
return a()
end
The premise of “a language like Python that works as you describe” is wrong too, since Python doesn’t work like that (it has the same hoisting and TDZ concepts as JavaScript):
def g():
def f():
return x
x = 4
return f()
print(g()) # 4You can't monkey patch lexicals, that is much of their point. Any reference to a lexical variable is a fixed binding.
In practice, this comes up most often for me when I have a script that I want to reload: if there are any toplevel `let/const`, you can't do it. Even worse, `class C { ... }` is also a lexical binding that cannot be replaced or overridden. Personally, I normally use `var` exclusively at the toplevel, and `let/const` exclusively in any other scope. But `class` is painful -- for scripts that I really want to be able to reload, I use `var C = class { ... };` which is fugly but mostly works. And yet, I like lexical scoping anyway, and think it's worth the price. The price didn't have to be quite so high, is all. I would happily take the benefit of avoiding TDZ for the price of disabling hoisting in the specific situations where it no longer makes sense.
I agree that hoisting is a backwards compatibility thing. I just think that the minute optional lexical scoping entered the picture, hoisting no longer made sense. Either one is great, the combination is awful, but it's possible for them to coexist peacefully in a language if you forbid the problematic intersection. TDZ is a hack, a workaround, not peaceful coexistence. (TDZ is basically the same fix as I'm proposing, just done dynamically instead of statically. Which means that JS's static semantics depend on dynamic behavior, when the whole point of lexical scoping is that it's lexical.)
function readfile(name)
local f <close> = assert(io.open(name))
return assert(f:read"a")
endIsn't that part still the crux of the article as it contains the answer to the title?
True, but you can at least wrap the entire scope and hack around it. It's not gonna be pretty or maintainable but you can avoid/override the code path that defines the let.
Anecdotally... I've monkeypatched a lot of JavaScript code and I've never been stopped from what I wanted to do, whereas with Python I've hit a dead-end in similar situations. Maybe there's some corner case that's unpatchable but I really think there is always a workaround by the ability to wrap the scope in a closure. Worst case you re-implement the entire logic and change the bit you care about.
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.
? 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.
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.
October 1, 2025
If you have been working with JavaScript for a while, you probably know there are a couple of different ways to initialize a variable. Nowadays we usually use
const password = "hunter2"
and only occasionally, if you need some mutable state:
let password = "hunter2"
These declarations have been around for a while and they have reasonable block scoping rules:
function example(measurement) {
console.log(calculation); // ReferenceError
console.log(anotherCalc); // ReferenceError
if (measurement > 1) {
const calculation = measurement + 1;
let anotherCalc = measurement * 2;
// ...
} else {
// ...
}
console.log(calculation); // ReferenceError
console.log(anotherCalc); // ReferenceError
}
But if you have been working with JS for a really long while, you might remember the time when neither of these declarations were possible. All we had was var. And var stinks. Not only is every variable mutable, with no way to enforce immutability, but to make matters worse, var leaks beyond block scope:
function example(measurement) {
console.log(calculation); // undefined - accessible! calculation leaked out
console.log(i); // undefined - accessible! i leaked out
if (measurement > 1) {
var calculation = measurement + 1;
// ...
} else {
// ...
}
console.log(calculation); // 1 - accessible! calculation leaked out
for (var i = 0; i < 3; i++) {
// ...
}
console.log(i); // 3 - accessible! i leaked out
}
Terrible!
So it was a big surprise to me to find out that the TypeScript codebase (which is itself written in TypeScript — for now ) is littered with var statements like it's 2003 :
/** @internal */
export function createSourceMapGenerator(
host: EmitHost,
file: string,
sourceRoot: string,
sourcesDirectoryPath: string,
generatorOptions: SourceMapGeneratorOptions
): SourceMapGenerator {
/* eslint-disable no-var */
var { enter, exit } = generatorOptions.extendedDiagnostics
? performance.createTimer("Source Map", "beforeSourcemap", "afterSourcemap")
: performance.nullTimer;
// Current source map file and its index in the sources list
var rawSources: string[] = [];
var sources: string[] = [];
var sourceToSourceIndexMap = new Map<string, number>();
var sourcesContent: (string | null)[] | undefined; // eslint-disable-line no-restricted-syntax
var names: string[] = [];
var nameToNameIndexMap: Map<string, number> | undefined;
var mappingCharCodes: number[] = [];
var mappings = "";
// Last recorded and encoded mappings
var lastGeneratedLine = 0;
var lastGeneratedCharacter = 0;
var lastSourceIndex = 0;
var lastSourceLine = 0;
var lastSourceCharacter = 0;
var lastNameIndex = 0;
var hasLast = false;
// ... etc
}
The reason has to do with what is called the Temporal Dead Zone (TDZ) . For each variable in your code, there is a zone where the variable is declared but not initialized. The following example makes this clear:
function example() {
const result = Math.random() < 0.5 ? useX() : 1; // 50% probability of a ReferenceError
const x = 10;
return result;
function useX() {
return x;
}
}
In the above example, it is totally valid to declare useX at the bottom of the function. The trouble comes when you call it before x has been initialized - in other words, when the interpreter is still in the TDZ of x. The interpreter refuses to let you access x and throws an error.
And that is great! Because if you would use var instead of const in this example, there would be no error and the function would simply return undefined!
function example() {
var result = useX(); // undefined
var x = 10;
return result; // undefined
function useX() {
return x;
}
}
console.log(example()); // undefined
Terrible!
So the TDZ is actually a super useful feature brought on by const and let. So why doesn't TypeScript want to use it? It's because Performance.
Figuring out whether it is in a variable's TDZ is a lot of work for the interpreter. As you can see above, it cannot be done statically, but depends on nondeterministic runtime behavior. That brings a penalty which was significant for the TypeScript codebase. After migrating a decent amount of their statements to var, they saw an 8% performance improvement across some benchmarks .
I for one am very happy that I don't have to use var anymore. And for TypeScript, I'm sure it's just another reason to migrate their codebase to Go .
Discuss this article on Reddit.
Feel free to email me at mail@vincentrolfs.dev. Or you can follow me on Mastodon at @vincentrolfs@hachyderm.io.