JS Demystified 04 — Execution Context
A humble attempt to demystify tricky concepts in JavaScript
JS Demystified Series
Intro
So far, we’ve looked at hoisting and scope in the JS Demystified series.
In my last post, I mentioned that scope and execution context are closely related, but not the same. Quite often, these two concepts are incorrectly understood and used interchangeably, which can lead to dangerous codes and bugs that are hard to track down.
In this post, we’ll explore execution context.
This is where we fit topics we’ve covered so far into a bigger picture, so make sure you have a good understanding of hoisting and scope before proceeding!
If you need a refresher…
JS Demystified 01 — Variable Hoisting
JS Demystified 02 — Function Hoisting
JS Demystified 03 — Scope
Alright, let’s dive in.
Execution Context ≠ Scope
It’s easier to demonstrate this with an example rather than with a wall of text. At this point, we just need to keep in mind that the following events happen, as the JavaScript engine starts to read your code.
- The global execution context is created before any code is executed.
- Whenever a function is executed (or called/invoked, these are all synonyms), a new execution context gets created.
- Every execution context provides
thiskeyword, which points to an object to which the current code that’s being executed belongs.
Now, consider this example.
Can you see that globalThis and this inside myFunc point to the same global Window object, even though we accessed the value of this from different scopes (line 1 and 4)?
This is because, I repeat, execution context and scope are not the same! However, scope plays a crucial part of how the execution context is defined.
So what exactly is execution context?
And what does scope have to do with it?
What is Execution Context
In JavaScript, execution context is an abstract concept that holds information about the environment within which the current code is being executed.
Remember: the JavaScript engine creates the global execution context before it starts to execute any code. From that point on, a new execution context gets created every time a function is executed, as the engine parses through your code. In fact, the global execution context is nothing special. It’s just like any other execution context, except that it gets created by default.
Memory Creation Phase
When a new execution context is created on a function call, the JavaScript engine needs to spend a little bit of time to configure it, in preparation for the execution. This is essentially what I have been referring to as the memory creation phase in my other articles.
The following happens during this phase.
- Creation of a scope
- Creation of a scope chain
- Determination of the value of
this
Let’s inspect each step in detail.
Scope
An execution context needs to know about its own scope — in other words, it needs to decide which variables and functions it has access to. Hoisting is performed at this stage, as the engine scans through your code for variable and function declarations, and puts them into memory.
Scope chain
In addition to its own scope, every execution context has a reference to its outer scopes (if any), all the way up to the global scope. This chain of reference is what we call a scope chain.
Important: A scope chain of a given execution context does not contain any information on its sibling scopes (those sit within the same outer function), nor on its children scopes (those sit within it). This is why a) you can access the global variable from local scopes, but not vice versa, and b) you cannot access local variable from other local scopes. See below.
Value of “this”
Every execution context also has a special variable this. I mentioned in the beginning that it points to an object to which the current code that’s being executed belongs.
In our demo, the value of this in the global execution context was the Window object. Interestingly, the value of this in the execution context of myFunc call also pointed to an identical object, Window.
So how do you explain this example?
Now, the value of this in the execution context of myMethod call is myObj instead of Window. Hmm… what’s happening?
Here’s the gotcha:
thisgets set to a leading parent object of a function call.- If there is no leading parent object,
thisdefaults to the global object (undefinedin strict mode).
Leading Parent Object
What do I mean by a leading parent object of a function call?
When myMethod was executed at line 12, it was precedented with a reference to myObj — this is the leading parent object. Hence, the value of this within the execution context of myMethod call was set to myObj. On the other hand, in the first example, myFunc call at line 9 did not have any parent object. Therefore, this defaulted to Window.
To make things even more interesting, let me throw you this example.
Can you guess what the value of this would be?
The answer is Window, not myObj. Why?
Let’s reiterate the description of how this is set to explain: this gets set to a leading parent object of a function at the time of execution.
Right, when the function was executed at line 8 — not when it was created inside myObj, not when it was assigned to myFunc — but when it was invoked, it did not have a reference to a parent object. This is why this defaulted to Window.
Now, you should be able to guess the next one right.
What would happen to this in a function call nested inside an object?
The same rule applies here, and the answer is Window again.
Got it?
“this” and “self”
So it looks like we don’t have much control over the value of this, right? Especially with the example of a nested function call, it seems extremely inconvenient that this points to a global object, where clearly the call sits inside an object.
One common way to control this inside objects is to assign it to a variable to preserve the value.
This way, self keeps the value of this at the time of assignment for later use. Some people use that as a variable name, but I personally prefer self, as it’s more descriptive.
bind(), call(), apply()
Another way to manipulate this is to use built-in methods: bind, call, and apply. Every JavaScript function can make use of these three methods via prototypal inheritance (woo, another beefy topic).
All of them essentially does the same thing — takes an argument and set it as the parent object of the execution context — with a slight difference.
bind: returns a function, which when invoked later will have a set contextcall, apply: immediately invokes a function with a set context
Let’s see them in action.
Note the () after the bind method. This is because bind returns a function to be executed later if so needed. It is practically same as doing:
var newShowGreet = showGreet.bind(casualGreet)
newShowGreet()// Hey!
I didn’t need to tell the JavaScript engine explicitly to execute in the case of call and apply, as they immediately invoke the function.
Execution Stack
So now we know how hoisting and scope fit into execution context. We know what exactly is execution context, when and how it gets created.
A simple rule: function call = new execution context.
But what’s next?
Say you have two function calls in your code. You will have three execution contexts in total, including the global execution context. To see how they all fit together, let’s go a step further and see the bigger picture — execution stack.
Once a new execution context is created, it gets placed on top of the previous context. Next time another function is executed, that execution context gets stacked on top, and so on. This is what we call the execution stack. It’s there for the JavaScript engine to keep track of the order of execution.
The important caveat here is that, the JavaScript engine can only be executing within a single context.
When you run the code, it starts off from the global execution context. When a function is called, it goes into the execution context of a, and everything that’s happening in the global context is paused, until the JavaScript engine exits the context a. If it encounters an execution within a before finishing the execution, another context b is created. The JavaScript engine pauses whatever that’s happening in the context a and goes inside b. As soon as the engine finishes executing the code there, the context b is removed from the top of the stack. Only then, does the engine go back to where it left off in the previous context a, and resume its execution. This cycle is repeated until the last line of code is executed in the global execution context.
This is why JavaScript is described as single-threaded, as only one thing can be processed at any given time, and multiple events have to happen in order, one after another.
Wrap-up
Cool! I hope you’ve got a better grasp of hoisting, scope and execution context. I would highly recommend to test out your own examples, and enhance your familiarity with these concepts. It forms an essential foundation to understand closures, which will be covered shortly in the series.
Please post any feedback, questions, or requests for topics. I would also appreciate 👏 if you like the post, so others can find this too.
Thanks, and see you next time!
