I've been learning a lot of Javascript lately and I've been trying to understand the value (if there is any) of hoisting variables.

I understand (now) that JS is a two pass system, it piles and then executes. Also, I understand that the var keyword 'exists' in the lexical scope it was declared, hence why it's 'undefined' if it's called before it's assigned a value by the engine.

The question is, why does that even matter? What use is there to hoisting variables that you can't do without hoisting? I feel like it just creates less-readable code with no gain ...

is there an example(s) of where hoisting variables is useful?

I've been learning a lot of Javascript lately and I've been trying to understand the value (if there is any) of hoisting variables.

I understand (now) that JS is a two pass system, it piles and then executes. Also, I understand that the var keyword 'exists' in the lexical scope it was declared, hence why it's 'undefined' if it's called before it's assigned a value by the engine.

The question is, why does that even matter? What use is there to hoisting variables that you can't do without hoisting? I feel like it just creates less-readable code with no gain ...

is there an example(s) of where hoisting variables is useful?

• javascript
• hoisting

• 3 JS is a two pass system, it piles and then executes that's sort of incorrect. The code could be piled but that would be implementation dependent. What you are talking about is the JS interpreter parsing the code and then executing it. However, as for usefulness of hoisting...I really can't think of a reason you really need to have it for variables. If you don't hoist, then if you do x = 42; var x would be an error...which I think is fine. – VLAZ Commented Oct 18, 2018 at 17:30
• 2 Possible duplicate of Why does JavaScript hoist variables? – Will Commented Oct 18, 2018 at 17:35
• @Will I'd agree with ments on that answer - it doesn't actually answer why you (as a language designer or even user) would want variables hoisted. It basically states that they are hoisted. It's with more words but it's what it boils down to. And the fact that they are hoisted...is readily apparent from the question. The rationale for variables hoisting mechanism isn't, though. – VLAZ Commented Oct 18, 2018 at 17:54
• 1 If you mean "hoisting" as "seed a new scope with all identifiers found in it", then I'd ask, what is the alternative? To only add the binding when the declaration is "executed"? So would var foo = 42; function bar() { console.log(foo); var foo = 21; }; bar(); log 42? Some languages do that... Or should it throw an error? (you get that with let and const). In the end, it's just one of the decisions one has to make when designing a language. I think it's generally agreed upon that initializing variables with undefined is sub-optimal, which is why we have let and const. – Felix Kling Commented Oct 18, 2018 at 18:40
• @vlaz While the other question might not have a satisfactory answer, I think the question itself is a duplicate. "Why does..." & "Is there a purpose to..." is equivalent, no? – Will Commented Oct 18, 2018 at 20:50

3 Answers 3

"Hoisting" is necessary for mutually recursive functions (and everything else that uses variable references in a circular manner):

function even(n) { return n == 0 || !odd(n-1); }
function odd(n) { return !even(n-1); }

Without "hoisting", the odd function would not be in scope for the even function. Languages that don't support it require forward declarations instead, which don't fit into JavaScripts language design.

Situations that require them might arise more often that you'd think:

const a = {
    start(button) {
        …
        button.onclick = e => {
            …
            b.start(button);
        };
    }
};
const b = {
    start(button) {
        …
        button.onclick = e => {
            …
            a.start(button);
        };
    }
};

There is no such thing as hoisting. Hoisting is merely a side effect of the pile phase that occurs and the fact that Javascript is lexically scoped. When the piler es to the pile phase it puts all variable and function declarations in memory as it figures out the lexical scopes that exists in the program. But there is no hoisting function or keyword or module. In fact it wasn't even reference in the Ecmascript spec before the es2015 release.

At the end of the day, hoisting is one of those million dollar words we all use, often because its easier to use rather than explain and discuss the pilation process that javascript goes through.

My suggestion would be to either read through the Ecmascript specs, work through a javascript engine source like v8, or read up on Kyle Simpson's work. He wrote a great series called You Don't Know JS.

Hope this helps!

Hoisting is a term you will not find used in any normative specification prose prior to ECMAScript® 2015 Language Specification. Hoisting was thought up as a general way of thinking about how execution contexts (specifically the creation and execution phases) work in JavaScript. However, the concept can be a little confusing at first. Conceptually, for example, a strict definition of hoisting suggests that variable and function declarations are physically moved to the top of your code, but this is not in fact what happens. Instead, the variable and function declarations are put into memory during the pile phase, but stay exactly where you typed them in your code. <- From the Mozilla docs

https://developer.mozilla/en-US/docs/Glossary/Hoisting

Not really. The only thing I can think of where it would be helpful is if you are writing code in a hurry and you happen to declare it later on. So it doesn't really matter, it's a weird addition to JS that a lot of people don't really even know about because utilizing it feels backwards and inefficient.