We're going to speak about the execution context and the call stack.

In order to make the entire subject more clear, we need to go to the very beginning and identify the starting point of our application between the script.

Tax will have the global scope, and what happens here is really just we're actually inside the main window object here.

It's just not being shown to us.

In other words, behind the scenes, JavaScript does something like this, it in Stan.

She hates the window object for the global scope, and that's pretty much what global scope is.

It's ah instance of the window object now because we are inside the we know object.

If you try to output this key word in the global scope, you'll notice that it actually equals the window object.

What's more interesting is that the window keyword itself, which waas in Stan cheated here, equals exactly the same thing.

And so this is actually why you can do something like this and compare that this object instance with the window it will actually be true because they're one and the same.

And for the same exact reason.

If you tried to compare the alert function, for example, to window dot Alert.

It will output true and again the same thing.

He's here because this is actually the instant sheeted object that is exactly the same as window.

Now there's a lot more to the this key word in any scope, including the global scope as well.

So what this usually refer to as the this binding and we're gonna explore the subject in just a moment.

Remember how, in my previous tutorial, we talked about Lex clean environments, and basically there were three different types of lexical environments the block scope, which is just the brackets without any context.

It's not a function.

It's not global context, just the brackets who treat anywhere, and you can ness them anywhere in your jobs.

Good application.

Then we have the global scope, which is really just the same as the window object we described here a moment ago.

And the third type of lexical environments is the function scope.

So this one's a little different, and that this binding can refer, sometimes to the global scope in the function.

In most of the time, it's referred to the function instance, itself We're going to take a look at this in a little more detail in just a second.

What is execution context?

Basically, execution context consists of three different things.

It's Dilek school environment.

Usually when we talk about execution context, the lexical environments will be talking about.

It will be either the global scope or the function scope.

Executing context is really not discussed in the context of blocks scope, because it's just even though that there isn't this key word available in the block scope just to describe the concept of how it all works.

These two different scopes are used generally to explain that, and so we got the lexical environment.

It's one of those scopes that we have just covered.

Variable environment is simply a place where you created variables.

It evaluates the values off the variables you created.

And one important thing to notice here is the variable environment is separate from the this binding.

So, for example, what I mean by that is when you create variables using far that gets landed into the variable environment or the same thing for let it still goes into the variable environment.

But when you start messing with this key word you're dealing with this binding and whatever this object is bound within the given scope.

In this case, it's a global scope.

So whatever that object is bound to in the scope is going to be accessed by the dot operator and indifferent scopes.

This key word can be referring to different execution contexts.

It's not always necessarily referring to the actual skull pits.

And in order to demonstrate how it actually works, I'm going to switch to a visual diagram that I created that should explain this entire process in greater visual detail.

And so, having said everything that we have mentioned so far up to this point, what is the call Stack and JavaScript?

The global scope is the very first layer of the execution context.

So whenever your browser runs your application, the first layer off execution context is created by the window object, which is the global scope.

Now let's say what create this function in the global scope and call it F A.

Inside this function, we assign the ex property on in this object to one, and so what happens here is that once we run, if a function because we're writing it from the global scope.

This object inside dysfunction will be actually equal to the global scope Object.

This is why, after we run this function, we try to output X on the window object that will get one.

It's the same value was set here because again, this key word inside the function that was called from the global scope will be bound to the global scope or the window object and not the function itself.

So in other words, what I'm saying is inside a function, this object is bound to the context from which the function was called.

In this case, it is window or global scope.

Usually, though, this is not considered as a good coating practice, because why would you want the inside scope over function have any ties to a global variable?

Usually that's not a very good code design idea, but that's just how Javascript works on this basic global scope level.

What actually happened here is this new execution stack was created, as you can see again, because the function was called from the global scope itself, and that this binding will be equal to the window object even inside of this function.

Now let's erase this example and I'll show you something else.

Let's use this key word in global scope to simply identify this space as global scope.

And now let's create a object literal.

And so in this object literal, we have a method here that will output the value off this A which was defined right here.

Now, in this case, notice how we have a variable a defined on in this object in global scope.

You also have property A on the object, literal.

Now, in this particular case because we're calling the method directly from the actual name of the object literal the property on then this object here will be valued to one and not global scope.

That's because the method here was not called from the global scope itself.

On the contrary, noticed that here we created a new variable called M and assigned this object method that we have just called here but noticed that this method is created in the global scope.

So what happens here is when we actually call the method M, the result of this operation will not be one.

It will be a global scope because again this method has been transferred into the global scope so that this context in this function will refer to the global scope variable defined by the global scope.

This instance, rather than what we define inside the object literal.

And this is happening because it was called from the global scope.

But in this instance, because it's called from the name of the object that was created is no longer called from the context of the global scope and for that reason that this key word here in the property, eh?

He's taking from the object itself.

So in a way, it's kind of locked inside.

It's private to this object.

In this case, when the execution of the script reaches this method, what's gonna happen?

Actually calling this method will create another execution context added to the call Stack wants.

This method returns, though, will disappear from the stack again as execution continues going down.

The descript eventually will arrive ad calling this function again, but this time from the global scope and it was gonna happen is that will create another execution context.

Once again, they will not be stacked one on top of the other because soon As this one finishes returning, it will disappear.

There are cases where you could just build these execution contexts into the stack by continuing calling a function inside the function.

And usually you will have several levels of thes execution context stacked one on top of the other as the functions inside functions are being cold.

And, of course, that this key word will continue being bound from whatever context the method was cold.

Now you'll have a lot of cases like this where you have a function calling another function, and it just keeps changing the function calls.

In this case, you will grow a taller call stack of all of this execution contexts, and one thing to notice here is because a the first function was called within the global scope.

What's gonna happen is you'll have a chain of this bindings all the way up to the function.

See which is the last one to be cold, and this function C will also within this function, this cured.

It's chained all the way back to the original been no object again because it's called from the global scope.

If you have functions Constructors executed using the new operator.

Then this chain would be broken.

A new operator creates its own context.

When you Kate Constructors, they totally just own this object.

And if you call any functions from that constructor, obviously they would inherit whatever that this object would be at that time.

But if you're just calling functions within the global scope and execute them starting from the 1st 1 and it goes into a B and C and so on so forth, you will retain the original global scope binding off this.

So it's sort of like a chain treated, and that goes all the way up to the number of functions that you're going to call.

And that's pretty much the idea behind call stack and execution contexts that keep stacking up on the call stack.

So thanks, guys, for watching my toil.