ECMAScript has an abstract concept called “execution context”, which means when control is transferred to the ECMAScript executable code, the control is then entered in a execution context.

So, what does the above statement mean? Well, it means every time a piece of code is executed in ECMAScript it has an execution context and the currently executing code is associated with that context. This can be conceived as some sort of container which encapsulates the context of the executing code, the could will look for its execution context for identifier and scope resolution. The execution context is not accessible to code; it is purely an implementation mechanism.

Active execution contexts form a “stack”, the bottom element of that “stack” is always the Global Context, where as the topmost element is the active or current execution context; whenever the control is transferred from the currently running executable code to a different piece of code which is not associated with the current execution context, a new  execution context is created and pushed onto the stack. The process of creating and removing execution contexts from the stack is a continuous thing.

Why execution context is so important? It is because execution context maintains the state  and execution progress of the code. It also determines what should be the value of the ‘this’ keyword associated with that execution context. The identifier resolution is also an important part of the execution context, because it is the mechanism which specifies how the binding of an identifier will be resolved in the current/active execution context. To put simply, identifier resolution is a process which determines how the JavaScript engine will retrieve the value of a particular variable and where it will look for.

The execution context is associated with the type of executable code. In JavaScript there are three types of executable code:

1. Global Code is the source code which is executed as ECMAScript program, for example – external JS file, inline script block in HTML pages are executed in the Global Context. So, when a global code is executed a global execution context is created and pushed onto the context stack.
2. Function Code is the source code which is parsed as the FunctionBody. The function code does not include body text of the nested functions. Invoking a function creates a new execution context every time, even in the case of recursive execution, and when the function returns, the corresponding execution context is popped up from the execution context stack.
3. Eval Code is the code that is the source text supplied to the built-in eval function. Eval code has a concept of calling context, which means the execution context from which the eval function has been called.

What happens when an execution context is created? A number of things happen when an execution context is created, if the type of code being executed is a function code then an “Activation Object” is created. Activation Object is a normal object without any prototype, which contains named properties. It stores information regarding variables and call arguments so that those are accessible to the execution context.

There’s more to execution contexts like scope chain, variable object and variable initialization. All of these I’ll cover in later posts. I assume the above explanation will serve as a primer on how the JavaScript engine works internally. Please do share your thoughts on this.

Update: For more detailed information on Execution Contexts check out this in-depth article written by Dmitry A. Soshnikov JavaScript Execution Contexts, do not forget to go through other articles written by him, those are an excellent source of information on JavaScript/Ecmascript internals.

ECMAScript 5 is on its way. Rising from the ashes of ECMAScript 4, which got scaled way back and became ECMAScript 3.1, which was then re-named ECMAScript 5

http://ejohn.org/blog/ecmascript-5-objects-and-properties/

ECMAScript is finally there, read the whole post by John Resig (Creator of  jQuery), and see the changes it brings to the JavaScript development, and the good news is that all major browser vendors agreed to implement this sooner than later. It has a detail description of how we will be accessing objects and it’s properties with some simple example code, to me this has opened a completely new era for JavaScript programming, though this specification brings real power to JavaScript which also comes with the cost of increased complexity, but as you know in any powerful language complexity is always there, it’s up to the developer how he/she can reduce the complexity but uses the full power of the language. Lastly, I just can’t wait to get my hands dirty with ECMAScript 5 .

Here is the little excerpt from that article:

I had the pleasure of showing off some the cool new features we’ve been adding to the WebKit inspector at JSConf last week. It’s no secret that debugging basically sucks in JavaScript, and until recently, it was a little bit worse in Objective-J. Up until now we’ve focused mainly on adding stop gap measures to our own code, but recently we’ve decided to shift gears and attack the problem head on in the browsers themselves. This is why these past couple of weeks I’ve set aside the JavaScript code and instead focused on working with the great guys on the WebKit team on providing a solid debugging experience both in Objective-J and JavaScript in general. We first decided to focus on profiling, since this is an area of considerable interest for a framework…

Read the detailed article here