Javascript Advanced: What is the Execution Context in Javascript

Execution Context

Then, a unique environment is created by the JavaScript engine of the browser to manage the transformation and execution of this JavaScript code. The Execution Context is the name given to this setting. The code that is presently running and all of the supporting data are both contained in the execution context. The specified code is parsed by a parser, the variables and functions are saved in memory, executable byte code is generated, and the code is executed during the Execution Context run-time.

Every piece of JavaScript code must be hosted and executed within a certain environment. Most frequently, a web browser would be that environment. Many operations occur in the background before any JavaScript code is performed in a web browser. We’ll examine everything that takes place in the background so that JavaScript code can run in a web browser in this article.

For those who are unaware, the high-level JavaScript code that we write in our applications is not natively understood by the browser. It must be transformed into machine code, a language that the browser and our computers can comprehend. While reading through HTML, if the browser encounters JavaScript code to run via a <script> tag or an attribute that contains JavaScript code like onClick, it sends it to its JavaScript engine.

There are two kinds of execution context in JavaScript:

1. Global Execution Context (GEC)
2. Function Execution Context (FEC)

Let’s take a detailed look at both.

Global Execution Context (GEC)

A default Execution Context called the Global Execution Context is first created whenever the JavaScript engine receives a script file (GEC). All JavaScript code that is not inside of a function is executed in the base/default Execution Context (GEC). One GEC may exist for each JavaScript file.

Function Execution Context (FEC)

When a function is called, the JavaScript engine creates a Function Execution Context (FEC), a unique sort of Execution Context, within the Global Execution Context (GEC), to analyze and run the code inside that function.

Since each function call receives its own FEC, a script’s run-time may have many FECs.

Let’s look at how execution contexts are produced now that we are familiar with what they are and the many varieties that are available.

There are two steps involved in creating an execution context (GEC or FEC):

1. Creation Phase
2. Execution Phase

Creation Phase

The Execution Context is first linked to an Execution Context Object during the construction process (ECO). The code in the execution context uses a large amount of crucial data that is stored in the execution context object during run-time.

The Execution Context Object’s properties are defined and set during the creation phase, which comprises three steps. These are the stages:

• The variable object’s creation (VO)
• Developing the Scope Chain
• Changing the “this” keyword’s value

Execution Phase

The execution phase of an Execution Context follows the creation phase immediately. The actual code execution starts at this point.

The VO has variables with undefined values up until this point. We cannot operate with undefined values, so if the code is performed at this point, errors would undoubtedly result.

The JavaScript engine then updates the VO with the actual values of these variables after reading the code in the current Execution Context once again. The code is then processed into executable byte code by a parser before being executed.

Lexical Environment

A specification object, “Lexical Environment,” only “theoretically” exists in the language specification to explain how things operate. We are unable to directly manipulate this object in our code.

As long as the visible behavior behaves as expected, JavaScript engines may also do internal tasks such as optimizing it, eliminating variables that aren’t needed to conserve memory, and more.

Example:

function outer() {
 
   var lang = 'Javascript';
 
   function inner() {
     console.log(lang);
   }
 
   inner();
 
}
 
outer();

Output:

Javascript

The output of running this code is the same as it was when the “outer()” function was used in the preceding example above. What makes this function unique (and intriguing) is that it is returned from the outer function before being performed.

Inner and Outer Lexical Environment

A closure is made of references to the state of the environment and a function that has been wrapped up (enclosed) (the lexical environment). In other words, a closure enables inner functions to access the scope of an outside function. Closures are formed whenever a function is created in JavaScript, during function creation time.

Example:

function outer() {
 
   const lang = 'Javascript';
 
   function inner() {
     console.log(lang);
   }
 
   return inner;
 
}
 
const langName = outer();
langName();

Output:

Javascript

The fact that this code still functions might not make sense at first look. In some programming languages, a function’s local variables are only present during the function’s execution. You could anticipate that the “lang” variable would no longer be reachable after “outer()” has completed running. This is obviously not the case in JavaScript, as the code still functions as intended.

Functions in JavaScript form closures are the cause. A function and the lexical context in which it was declared are combined to form a closure. Any local variables that were in-scope when the closure was established are included in this environment. When the function “outer()” is called, an instance of “inner()” is created, and in this case, “langName” is a reference to that instance.

The instance of “inner()” keeps track of the lexical context in which the variable name is present. Because of this, “Mozilla” is sent to console.log when “langName” is used, and the variable name is still usable.

Dynamic vs Lexical Scope

Lexical scoping is the process by which the variables that are available to you depend on where a function is defined. Dynamic scoping, on the other hand, uses the function’s invocation location to determine which variables are accessible.