Is correct to think of all JS code & variables as being a property of an execution context?

Question

I may be wrong, but it seems safe to conceptualize everything in JS code as being a property of an execution context (either a global or function or eval() execution context). Why?

every execution context has unique lexical/var environments as properties. (New run = new ex. context = new instances of variableEnv objects = new variables with new references)
and these lexical/var environments contain all your variables (identifier-value mappings).

Closures might be a good supporting example:

function function0(sizevar) {
    s = sizevar * 2;
    return function function1() {
     console.log(s);
        console.log(sizevar);
    };
}
    
var size12 = function0(12);
var size14 = function0(14);
size12()
size14()

So from the above^, when you return an embedded function1, you’re returning a reference to a function instance/object that’s a property of one specific execution context’s lexical/variable environment.

And when function0() returns function1(), scope chain is tied to an execution context’s state (i.e. its variableEnv), even if that execution context is done executing.

Is this a correct or incorrect way to think of JS variables?

Anyone have a link/code/image of an actual JS execution context object?

`Closure` is the concept that allows a function to "capture" the context in which it was defined, after the flow of execution has left that context. See https://stackoverflow.com/questions/111102/how-do-javascript-closures-work — user229044, Jun 28 '19 at 13:29
It is also called "scope". Your example would benefit from being included as a javascript code snippet, so people can click "run" and get some output. — Adder, Jun 28 '19 at 13:30
@meagar Can a closure be less ambiguously defined as: a function "capturing" references to the outer lexical environment objects of the execution context in which the function was interpreted? These lexical environment references make up its scope chain, and these lexical environment objects persist even after their execution context has completed. These lexical env. objects are not garbage collected, as a closure function has a "captured" that reference. — AnonEq, Jun 28 '19 at 13:51
I think everything you said is correct and you can rely on that paradigm. Nothing left to say, i thought the topic got closed ~10 years ago — lucifer63, Jun 28 '19 at 13:56
Nitpick: `s` is actually global, not part of the execution context — Patrick Roberts, Jun 28 '19 at 14:08
@PatrickRoberts Everything is part of an execution context. s is part of the global execution context's lexical environment, no? Not sure what you're 'nitpicking' here or what you mean by 'the' execution context. — AnonEq, Jun 28 '19 at 14:21
@AnonEq yes it's part of _an_ execution context, not _that_ one. It should be declared with `var`, `let` or `const` in order to be part of _that_ execution context specifically. — Patrick Roberts, Jun 28 '19 at 14:23
@PatrickRoberts Right, thanks. I think I get what you mean by nitpicking here now: 'specifying this learning-opportunity nuance for all onlookers', rather than nitpicking as in 'fault-finding'. — AnonEq, Jun 28 '19 at 14:46

score 3 · Answer 1 · answered Jun 28 '19 at 14:19

Is this a correct or incorrect way to think of JS variables?

Yes, this is a fine way to conceptualise scopes. But remember it only is a concept, and an actual js engine might implement it different (especially, optimise the heck out of it). It will still have the same results as the model, though.

Anyone have a link/code/image of an actual JS execution context object?

I found several good illustrations at

(but won't copy the images here to respect the copyright of the respective authors)

Is correct to think of all JS code & variables as being a property of an execution context?

1 Answers1