JavaScript Hoisting

Introduction

Hoisting is one of the most misunderstood ideas in JavaScript. Many developers picture the engine physically moving lines of code to the top of a file. That is not what happens.

Hoisting is the engine's behavior during the creation phase of an execution context: it scans declarations, allocates memory, and registers bindings before any statement runs. The source file order never changes — only the in-memory setup does.

This guide covers:

1. The core concept — what hoisting really means
2. Execution context phases — where hoisting happens
3. Variable hoisting — var, let, and const
4. Function hoisting — declarations vs expressions
5. Best practices — how to write code that avoids hoisting pitfalls

Related reading: JavaScript Execution Context for the full runtime model behind hoisting.

Course Reference

Quick index

1. What is hoisting?

When JavaScript enters a new execution context, the engine performs two distinct phases before your program finishes:

Hoisting refers to the creation-phase behavior where the engine registers variable and function declarations in memory. It is a conceptual label — no code is physically moved to the top of the file.

console.log(greeting) // undefined (not ReferenceError)
var greeting = 'Hello'
 
sayHi() // 'Hi!' — works before the function line
 
function sayHi() {
  console.log('Hi!')
}

From reading the file top to bottom, greeting and sayHi appear to be used before they exist. In reality, the creation phase already registered both before line 1 executed.

Back to index

2. Where hoisting happens

Hoisting is not a standalone feature — it is a consequence of how execution contexts boot up.

Creation phase checklist

1. Create the variable environment and lexical environment
2. Scan the scope for var, function, let, and const declarations
3. Allocate memory for each binding
4. Initialize var to undefined and store full function declarations
5. Leave let/const uninitialized (temporal dead zone)
6. Set up the outer scope reference and this binding

Execution phase checklist

1. Run statements top to bottom
2. Assign actual values to variables
3. Execute function bodies when functions are invoked

// Creation phase registers: count → undefined, greet → full function
// Execution phase runs each line in order
 
console.log(typeof greet) // 'function'
console.log(typeof count) // 'undefined'
greet()
 
var count = 10
function greet() {
  return 'Hello'
}
let label = 'JS'

Interactive: hoisting memory scanner

Back to index

3. Variable hoisting

Not all declarations behave the same during creation.

var — initialized to undefined

console.log(x) // undefined
var x = 5
console.log(x) // 5

The binding exists before line 2 runs, but its value is undefined until assignment.

let and const — temporal dead zone

console.log(y) // ReferenceError
let y = 5
 
console.log(z) // ReferenceError
const z = 10

Both are registered in memory during creation, but accessing them before their declaration line throws a ReferenceError. This is the temporal dead zone (TDZ).

Interactive: variable hoisting compare

Back to index

4. Function hoisting

Functions follow different rules depending on how they are defined.

Function declarations — fully hoisted

greet() // 'Hello'
 
function greet() {
  return 'Hello'
}

The entire function — name and body — is stored in memory during creation. You can call it before the declaration line.

Function expressions — variable hoisting rules apply

sayHi() // TypeError: sayHi is not a function
 
var sayHi = function () {
  return 'Hello'
}

Here sayHi is a var. Creation phase sets it to undefined. Calling it before assignment throws TypeError because undefined is not callable.

sayHi() // ReferenceError
 
const sayHi = () => 'Hello'

With const or let, the binding is in the TDZ — you get ReferenceError, not TypeError.

Named function expressions

const factorial = function fact(n) {
  return n <= 1 ? 1 : n * fact(n - 1)
}
// `fact` is only visible inside the function body

The outer name follows variable hoisting rules; the inner fact name is local to the function.

Interactive: function hoisting explorer

Back to index

5. Best practices

Hoisting explains odd behavior — it should not be something you depend on in production code.

Declare before use

// Avoid
console.log(total)
var total = calculateTotal()
 
// Prefer
function calculateTotal() {
  return 100
}
const total = calculateTotal()
console.log(total)

Use let and const instead of var

var hoisting to undefined silently hides bugs. Block-scoped let/const with TDZ catch mistakes at the declaration line.

// var leaks and hoists oddly in blocks
for (var i = 0; i < 3; i++) {}
console.log(i) // 3
 
// let stays block-scoped
for (let j = 0; j < 3; j++) {}
// console.log(j) // ReferenceError

Put function declarations before calls (or use expressions after setup)

// Clear intent — no reliance on hoisting
function init() {
  bindEvents()
  fetchData()
}
 
function bindEvents() {
  /* ... */
}
function fetchData() {
  /* ... */
}
 
init()

Understand execution context for debugging

When you see unexpected undefined, TDZ errors, or "is not a function", trace:

1. Which execution context is active?
2. Has the creation phase registered this binding?
3. Has the declaration line executed yet?

Back to index

Conclusion

Hoisting is not magic and it is not code rearrangement. It is the engine preparing memory during the creation phase of each execution context.

Key takeaways:

• Hoisting = creation-phase memory allocation for declarations
• var → hoisted and initialized to undefined
• let / const → hoisted but TDZ until the declaration line
• Function declarations → fully hoisted with body
• Function expressions → follow the variable rules of their binding
• Best practice → declare before use; prefer let/const over var

Pair this guide with JavaScript Execution Context for the full picture of how code actually runs.

Have questions about hoisting or the temporal dead zone? Reach out via the contact page.