JavaScript Execution Context

JavaScript developers do not pay attention much on internals of JavaScript execution, namely execution context. Even experienced JavaScript developers may lack necessary knowledge about execution context.  Nevertheless, concept of execution context is simple. It consists of details for the environment of a function that is executed. To make execution context more clear, we will try to give some insight and a concrete mental model for understanding of execution context.

First of all, there are two types of execution context, which determine how and where code is evaluated, the first one is the global and the second one is the functional. Global context can be accessed from anywhere in the program and represents the base execution environment created when the JavaScript engine starts, while functional context can be accessed by function itself and inner functions of it and is created every time a function is invoked. Accessing parent function context results in Scope Chains, a core JavaScript mechanism, which is ability to access scope of calling function by walking outward through nested execution contexts. Let’s examine global and functional context with an example.

//global context
var x = 1;
function foo(){
   //foo context
   var y = 2;
   //console.log(x+","+y+","+z); (1)
   return function inner(){
      //inner context
      var z = 3;
      console.log(x+","+y+","+z); //(2)
   }
}
//console.log(x+","+y+","+z); (3)
foo()();

From the above code snippet, first(1) log will give a reference error because of the variable z, since z is declared inside outer() and is not visible in the global scope where log (1) runs. second(2) log will execute just fine because it runs inside outer(), so z exists in that execution context and can be resolved normally, and the third(3) log will give a reference error for y because y is declared inside inner() and is not visible in outer() once you are back in outer()’s body. The references errors occur because current execution context cannot resolve the identifiers during identifier lookup, the engine checks the current lexical environment first, then walks outward through the scope chain, and if it never finds a binding, it throws ReferenceError. But, each inner function can see its outer function variables because the scope chain includes the outer lexical environment, so inner() can read z (and any other bindings from outer()). After giving this basic example, let’s dive into details.

Browsers interpret JavaScript single threaded, so there is no true parallel execution in the same JS runtime, which means one thing can be done at one time per thread. Similarly, we can see one execution context at one time because the engine is always inside exactly one context while executing. When a page loads, global execution context is created and put into execution context stack as the very first frame. After that, interpreter creates a new execution context for each function call (every invocation, not declaration) while preserving scope chains so identifier lookup still works across nested functions. Besides, each created execution context is put into stack with respect to their order (last called, first executed/finished). When any of execution context is finished, interpreter removes it (pops it off the stack) and continues to execute previous execution context from where it paused. Below, you can see the figure representing stack for execution context.

Moreover, execution contexts have a life cycle, that can be divided into creation and execution phase, so the engine always does a setup pass first, and only then starts running your code. In creation phase, interpreter follows the steps below, in a predictable order that explains hoisting, this, and why some identifiers exist before a line is executed:

1. Each variable, function or argument is created.(Variable Object is created)
2. Scope Chain is initialized.
3. Value of “this” is determined.

In execution phase, code is interpreted and executed, meaning statements actually run line by line and assignments finally get their real values. Now, let’s observe each steps of creation phase thoroughly, because this is where most “JavaScript magic” people talk about is actually happening.

In creation phase, variable object is created first, a structure that will hold identifiers (functions, variables) for that execution context. Then, arguments object is created, so the function can access passed parameters via arguments (even if you did not name them explicitly). After setting necessary objects, interpreter scans for function declarations and creates a corresponding property for each function in variable object, which is why function declarations are usable before their appearance in the source code. If there is already reference for the function in variable object, interpreter just overrides it, so later function declarations with the same name win during creation. The same process followed for variable declarations but interpreter just passes declarations that already exists in variable object, meaning var declarations do not overwrite existing function bindings, they only ensure the name exists (initialized as undefined until execution phase assigns a value). After finalizing variable context, scope chain is created, linking this context to its outer lexical environment for identifier lookup, and we are ready to run the function, by entering the execution phase with that environment already prepared. Let’s see below function and how it looks like in creation stage, so you can literally map these steps to a concrete example.

function foo(z){
   var x = "Hello World!";
   var y = function(){
      alert(x);
   };
   function f(){};
}
foo(13);

Our function looks like as follows in creation stage.

executionContextForFoo(){
   variableObject : {
      arguments : {
         0 : 13,
         length : 1
      },
      z : 13, // Remember, reference to functions created first.
      f : pointer to the function f 
      x : undefined,
      y : undefined
   },
   scopeChain : {...},
   thisForFoo : {...}
}

At this point, hoisting occurs since we first create pointers to the functions and variables, then execute. Let’s look at below example.

(function(){
    alert(typeof hello);//prints pointer to hello function
    alert(typeof hi);//prints undefined
    var hi = function(){
       alert("Hi!");
    }
    function hello{
       alert("Hello!");
    }
})();

Function declarations are always hoisted, meaning the entire function is available before execution reaches its line, and any variable declared with var is initialized to undefined during the creation phase. In the above example, hi is a variable and defined as undefined in the variable object until the assignment runs in the execution phase.

In short, we have tried to explain execution context and give an overview, so you can connect hoisting, scope chains, and the call stack to one consistent mental model instead of memorizing rules.

Good Reads

• David Shariff’s post
• John Resig’s Learning Advanced JavaScript
• Ecma-262