Forem: Guilherme Scotti

JavaScript Demystified: Unveiling the Code Wizardry - Hoisting

Guilherme Scotti — Sat, 17 Feb 2024 20:52:44 +0000

People commonly explain hoisting as declarations of variables and functions being moved to the top of your code. At the same time, this appears to be happening; it’s essential to understand precisely what is happening. Because that definition is a Myth, a convention created to discuss the idea of lexical environment without so much overhead.

Before the ECMAScript® 2015 Language Specification, "hoisting" was not used in any normative specification.

foo("My Name");

function foo(name) {
  console.log(name);
}

In this case, the function was called before its definition. People often claim that the function is "lifted" to the beginning of the code, but it works due to function prototypes.

function foo(name) {
  console.log(name);
}

foo("My Name");

But that's incorrect, there's no such thing as lifting functions and variables, you see, the code isn’t moving anywhere. It isn’t magically being moved to the top of the file. At the compiler phase, all functions and variable declarations are Hoisted at the Memory Heap, called the Lexical Environment. Then, the Engine will execute the code from top to bottom, adding every scope at the Execution Call Stack.

Hoisting refers to the default behaviour of Javascript to process and put all variables and function declarations into memory first during the compile phase of its execution context, regardless of where they are written in the code. Maya Shavin

Lexical Environment is a data structure with identifier-variable mapping on the memory heap.

Difficult? Too many concepts? let's make it more simple. A few seconds before your code is executed, the compiler will go through every line, collecting variables and function declarations and storing those in the memory to optimise and utilise even before his declaration in the source code. In other words, the lexical environment is a fancy way to say "local memory scope".

Let's see if those concepts can be put into practice.

say("Hello"); // Hello
console.log(world); // world is undefined

function say(word) {
  console.log(word);
}

var world = "World";

So, in this example, the compiler will run through the code and find the function say and save his reference into the memory, making it available to be called in the execution phase, returning 'Hello', but why the world variable is undefined?

JavaScript only hoists variable declarations.
Initializations are not hoisted.

So the variable declaration world will be hoisted at the memory. In the execution phase, the variable is called, but since it isn't initialized yet, the returned value is undefined; here's another example.

if (x === undefined) {
  console.log("x is not defined");
} else {
  console.log(x);
}

var x = "Defined";

//result "x is not defined"

Here the x variable is stored in memory during the compile phase but with the value of undefined, because the assignment of value to a variable happens only in the execution phase.

So what happens is something like this before the execution phase

var x;

if (x === undefined) {
  console.log("x is not defined");
} else {
  console.log(x);
}

x = "Defined";

//result "x is not defined"

Let's see what happens if we swap the declarations of the variable 'x'

var x = "Defined";

if (x === undefined) {
  console.log("x is not defined");
} else {
  console.log(x);
}

//result "Defined"

This time, the variable x will be hoisted/lifted by the compiler with the value of undefined, but when the execution phase starts, the x variable will be evaluated at the first line with the value of Defined making possible to run the else condition.

There's also a lot of confusion about undefined and undeclared variables (Reference Error). When a variable is undefined, it means that the variable has been declared at the compiler phase but not initialized, and undeclared are variables that weren't declared in the lexical environment or the JS Engine doesn't find an available reference for them.

What happens with ES6 syntax?

So, what happens with all the features of ES6, like let and const? Are they hoisted? let's see

console.log(x);
//ReferenceError: x is not defined

let x = "Hello";

All declarations in JavaScript function, var, let, const, even classes, are hoisted at the compiler phase, but while the var declarations are initialized with undefined, let and const declarations remain uninitialized, so where it's at the first line of the example? he was in a place that we call "Temporal Dead Zone".

No, nothing like that, let's see what ECMAScript 2015 spec tells us about TDZ.

NOTE 13.2.1 Let and const declarations define variables scoped to the running execution context’s Lexical Environment. The variables are created when their containing Lexical Environment is instantiated but may not be accessed in any way until the variable’s LexicalBinding is evaluated. A variable defined by a LexicalBinding with an Initializer is assigned the value of its Initializer’s AssignmentExpression when the LexicalBinding is evaluated, not when the variable is created. If a LexicalBinding in a let declaration does not have an Initializer, the variable is assigned the value undefined when the LexicalBinding is evaluated.

In other words, let and const are only initialized when their assignment of value is evaluated, and that happens during the execution phase, so in the example, the x variable will be evaluated only after called by console.log, that's why throws a ReferenceError.

Now, let's see what happens when we introduce the block scope.

var name = "Guilherme";
displayName();
function displayName() {
  console.log(name);
  // ReferenceError meaning TDZ error
  let name = "Scotti";
}

Now, the global scope has a name variable with the value of 'Guilherme', but when the Engine enters the block scope, it creates another execution context and hoists the variable name into the TDZ of this block context. So, when the console.log runs, the variable name is unreachable.

To summarise, TDZ means don't touch that until it is initialized.

The whole point of the TDZ is to make it easier to catch errors where accessing a variable before it’s declared in user code leads to unexpected behaviour. This happened a lot with ES5 due to hoisting and poor coding conventions. In ES6 it’s easier to avoid.

Function Expressions or Declarations

There are three ways to define a function in JavaScript: a function declaration (assigning the function value into a variable), function expression, and ES6 Arrow Functions. So, are they all Hosted equally?

hello(); // "Hello"
world(); // TypeError: world is not a function
exclamation();
// ReferenceError: exclamation is not defined

function hello() {
  console.log("Hello");
}
var world = function() {
  console.log("World");
};
const exclamation = () => console.log("!");

We already know that Function Declarations are Hoisted during the compile phase, so the hello() function is ready to be called at line 1 because it's a function declaration.

At line 2, we call the function world(), but actually, we are calling the variable world that was hoisted with the same rule as any other variable with the default value of undefined. Therefore, when the execution reached line 2 and tried to call world(), it failed returning a TypeError, because undefined is not a function!

That also happens with the arrow function, but with a little difference: ES6 Syntax is initialized only at value evaluation on the execution phase, so there's the Reference error because of the const declaration.

Conclusion

This is an important foundation in the understanding of how JavaScript works under the hood, and the main conclusion that can be drawn is that all declarations in JavaScript function, var, let, const, even classes, are hoisted at the compiler phase, but with different assignments of value. Variables are hoisted with the value of undefined, except const and let, which are only initialized when their assignment of value is evaluated, and that happens during the execution phase; before that, they are in TDZ.

We also saw that function declarations are hoisted and evaluated normally, but function expressions are treated precisely like variables. I hope you guys can glimpse some functionalities that run on our daily code in JS.

Now that you know more about Hoisting, it’s time to move to dive Deeper with Javascript Demystified Series.

If you want to dive deeper into some concepts, visit the References. Please post any feedback, questions, or requests for topics. I would also appreciate 👏 if you like the post so that others can find this too.

JavaScript Demystified: From Compilation to Execution

Guilherme Scotti — Sat, 17 Feb 2024 20:03:57 +0000

We must examine how our code runs when executed to understand better how JavaScript works under the hood. By the end of this post, you should understand what execution context is and why it is essential to understand some core principles of JavaScript, like Hoisting and Closure.

[TL;DR] This explores JavaScript execution and the debate of whether it is compiled or interpreted. JavaScript engines manage code execution through Execution Context and define environments. The compilation phase creates Scope Chain and hoisting while the execution phase brings the code to life.

How does JavaScript work under the hood?

How is JavaScript executed in browsers? Is it compiled or interpreted? There is a lot of debate about whether JavaScript is a compiled or hybrid language. However, one reliable specification is available.

JavaScript is a lightweight, interpreted language MDN

I'm unfamiliar with compilers so that I won't delve into details. However, this knowledge is essential to better understand some of the language's logic.

There is a temptation to think that JavaScript code is interpreted line-by-line, top-down in order, as the program executes and therefore not compiled. However, while that is substantially true, one part of that assumption can lead to incorrect thinking about the language, and that's what we are going to see.

JavaScript is an interpreter-agnostic language

Therefore, the language is interpreted, but there isn't an official JS Engine designed for the language. Web Browser vendors created a lot of Engines, which essentially make all the magic happen.
But that concept diverges a lot; some academics suggest that it is a compiled language, and many blogs and posts say that it is a hybrid language. The official standard specification says:

Therefore the language is interpreted, but there isn't an official JS Engine for the language, and the community created a lot of Engines to suppress that need.

JS Engines

While each JavaScript engine varies in its implementation details, the intention here is not to delve too deeply into those specifics; instead, we will focus on the broader aspects of code execution. These engines play a pivotal role in interpreting JavaScript code, yet they operate under a distinct constraint compared to languages like Java or C#. Unlike languages that undergo extensive compilation before execution, JavaScript engines, whether in a browser or Node.js environment, do not have the luxury of ample compilation time.

As JavaScript code runs, the engine initiates the processing sequence, navigating through a series of steps, with one critical phase being the Execution Context. This context encompasses the environment in which the code is executed, including variables, functions, and the scope chain. Understanding the intricacies of the Execution Context is vital for developers seeking to optimize their code for performance.

Execution Context

Execution context is defined as the environment in which the JavaScript code is executed.

When code is run in JavaScript, the environment in which it is executed is very important. By the environment, I mean variables, objects, this, functions, and every Execution Context in JavaScript must be one of these three types:

Global Context: The main execution context in which JS code starts its execution when the bundle first loads at the browser.
Function Context: This is the context created by executing the code inside a function, and that environment has access to the global Environment.
Eval: An execution context confined within the eval function adds complexity to the script. While subtle, Eval introduces a unique dynamic, influencing the course of execution.

However, to create these kinds of contexts, the Engine must go through a series of stages, and we are going to focus on the two most important stages

Compilation / Creation Phase
Execution Phase

At the compilation phase, the Engine scans the code line-by-line, top-down, to create the Scope Chain, Hoist variables and functions and determine the value of "this". Essentially, all that happens a few microseconds before the execution phase, thus leading to the misunderstanding between interpreted or compiled language, knowing that it's essential to understand some key concepts of how the language works.

After the compilation phase is complete, the execution of the code starts. Let's visualize it with an example:

//The code simply calls itself 3 times, incrementing the value of ´i´ by 1.
function recursive(i) {
  if (i === 3) {
    return;
  } else {
    recursive(++i);
  }
}
recursive(0);

Every time a function is about to be executed, a context is created for it and added to the Stack. Once all the function's code is executed, JS engines pop out that function. Each function call creates a new context, creating a Lexical Scope where anything declared inside the function can not be directly accessed from outside the current function scope.

Conclusion

Understanding the inner workings of JavaScript execution is crucial for developers. The debate over whether JavaScript is compiled or interpreted has nuances, and it's essential to grasp the role of JavaScript engines in executing code. JavaScript is an interpreter-agnostic language. Therefore, the language is interpreted, but there isn't an official JS Engine designed for the language; due to that, Web Browser vendors created many Engines responsible for interpreting the code and creating the Execution context, which is the environment where the code is executed.

Those environments are created in two stages, the Compilation and the Execution stage, and they are responsible for creating the Scope Chain, hoisting variables and functions, and executing the code.

The heart of this process lies in the Execution Context, where the environment for code execution is defined, comprising Global, Function, and Eval contexts. Delving into the compilation and execution phases unveils the intricacies of creating the Scope Chain, hoisting variables and functions, and determining the value of "this."

Now that you know more about Execution Context, it's time to move to the next chapter of this series of articles and learn more about Hoisting. did you know the term "hoisting" didn't exist at EcmaScript Specification until the ES6 release?