DEV Community: Aditya Tripathi

Javascript "this" binding with examples

Aditya Tripathi — Sat, 18 Nov 2023 17:31:15 +0000

In this article, we will explore a runtime construct for JavaScript language called this. Compared to other languages, this behaves differently in JavaScript.

this keyword is a way to implicitly pass information of an execution context to running execution context. If you are not sure what those terms mean, checkout out my other articles on JavaScript Runtime and JavaScript Scopes in-depth.

It is a way to provide data implicitly between different scopes.

The value of this depends on which object it is bound to in runtime. This binding is decided using a set of rules which are always decided on the function call-site, and not where function is declared.

Let us try to understand this with a very simple example:

var me = {name: 'Writer'}
var you = {name: 'Reader'}

function printNameImplicit(){. // declaration site
    console.log(this.name)
}

printNameImplicit.call(me) // call-site 1
printNameImplicit.call(you) // call-site 2

Using call (more on it later), we bind this of printNameImplicit function (or of the scope created by the function) to any object we want. this value then becomes that object, and name is displayed accordingly.

In a way, we "imported" me and you object in printNameImplicit function's scope at runtime.

Consider another example:

var person = {name: 'Adam'}

function addAge(age){
 this.age = age;
}

function addAddress(address){
 this.place = address
}

addAge.call(person,20);
addAddress.call(person,'House 1, Street A')

console.log(person) //{ name: 'Adam', age: 20, place: 'House 1, Street A' }

Using this we can build up an object or modify its existing properties.

Bindings

As we have seen above, call helps us bind this of a function to an object. It takes two parameters, the first being the object we need this to be bound to, the second is the argument required by the function whose this is being bound.

But what happens when we have multiple arguments for the function? We can pass subsequent parameters to call or
we can use a very similar construct called apply. It is almost identical to call except that its second parameter is an array of values, representing multiple parameters of the function. If we modify our above example, by combining the functions:

var person = {name: 'Adam'}

function addAddressAndAge(address, age){
 this.place = address
 this.age = age;
}

addAddressAndAge.apply(person, ['House 1, Street A', 20]);
// or addAddressAndAge.call(person, 'House 1, Street A', 20);

console.log(person) // { name: 'Adam', age: 20, place: 'House 1, Street A' }

As mentioned above call and apply are methods are a way to bind this to an object. By default, in non-strict mode, this is bound to the Global Object. In strict mode, this is bound to nothing and hence its value is undefined. This scenario is called as default binding.

// non-strict mode
var a = 10;

function print(){
 console.log(this.a)
}

print() // 10

In the above example, this is bound to global scope. In strict mode, the result would be undefined instead.

Implicit Binding

Implicit binding refers to this being bound to the object decorated on the call-site of the function. Consider the following example:


function printName(){
  console.log(this.name)
}

const person = {
  name: 'Adam',
  printName: printName // implicit 'this' binding
}

person.printName();  // call site decorated with person object

When we modify object person to include printName inside it, the this of printName is implicitly bound to person if the function call is made using the person object.

Also note that only the closest object reference at call site is bound to this. For eg. if we do:

function printName(){
  console.log(this.name)
}

const person = {
  name: 'Adam',
  printName: printName // implicit 'this' binding
}

const anotherPerson = {
  name: 'Eve',
  friend: person
}

anotherPerson.friend.printName(); // Adam

friend, i.e. person object will be bound to 'this' because it is closer to printName function call.

Implicit bindings are lost when the call-site is undecorated. When implicit bindings are lost, they fallback to default binding.

let name = 'Eve'

function printName(){
  console.log(this.name)
}

const person = {
  name: 'Adam',
  printName: printName // implicit 'this' binding
}

printName() // Eve, in non-strict mode, undefined in strict

Implicit bindings are also easily lost or re-bound in-case of assignments and callbacks.

let name = 'Eve'

function printName(){
  console.log(this.name)
}

const person = {
  name: 'Adam',
  printName: printName
}

setTimeout(person.printName, 1000) // Eve, implicit binding lost

In other words it do not automatically forms a closure with the bound object.

Explicit Binding

Explicit binding, as the name suggests, is when we explicitly bind this to an object using constructs like call, apply or bind which we saw above. Unlike implicit binding, explicit binding constructs allow us to bind this without actually altering the object its bound to.


function printName(){
  console.log(this.name)
}

const person = {
  name: 'Adam',
  age: '32'
}

printName.call(person); // Adam
printName.apply(person); // Adam

However, explicit binding does not cure the problem of losing our bindings and is fragile like implicit binding. To tackle this, we can perform a certain type of explicit binding called as hard explicit binding or just hard binding.

Hard binding wraps the call-site in a wrapper function, this makes sure that the scope in which a function's this is bound to the target object is not influenced by other scope.


function printName(){
  console.log(this.name)
}

const person = {
  name: 'Adam',
  age: '32'
}

let hardBind = function (targetFunction, targetObject){
  targetFunction.call(targetObject)
}

setTimeout(() => hardBind(printName, person), 1000); // Adam

Here, we provide a wrapping function, so that our calling code (which is setTimeout) is forced to perform binding through that wrapper function only, making sure that whenever printName is called, its this is bound to the personObject.

The above example utilises Closures. If you do not understand how? Take a look at my article on closure: JavaScript Closures with examples

The wrapper function is a common binding design pattern in JavaScrip and hence it is supplied as a default construct by the language in the name of bind. The bind returns a function which is called every-time we want to perform hard binding.


function printName(){
  console.log(this.name)
}

const person = {
  name: 'Adam',
  age: '32'
}

let hardBind = printName.bind(person)


setTimeout(() => hardBind(printName, person), 1000); // Adam

`new` Binding

To understand this binding created by new operator, let us quickly refresh how new works.

Calling any function with new makes it a constructor call. A constructor calls returns a newly created object, unless the function being called returns its own object.

The new operator binds the constructor function's this to this newly created object.


function Person(name, age){
  this.name = name;
  this.age = age;
}

let person = new Person('Adam', 32)

console.log(person) // Person { name: 'Adam', age: 32 }

Arrow Functions

this behaves differently from arrow functions. Unlike regular functions arrow functions do not have their own this, they form a closure with the this value of enclosing scope. This behaviour is sometimes useful when we do not want to shadow this value by creating our own for each function declared.

const obj = {
 // implicitly bound this  
 getThisGetter() {
    const getter = () => this;
    return getter;
  },
};


const fn = obj.getThisGetter();
console.log(fn() === obj); // true

const fn2 = obj.getThisGetter;
console.log(fn2()() === globalThis); // true in non-strict mode

this keyword in JavaScript plays a crucial role in determining the runtime binding of functions to objects. Unlike many other programming languages, this in JavaScript is dynamic and relies on the rules set during the function call-site, not the declaration. We explored how this can be explicitly bound using methods like call, apply, and bind, allowing for flexibility in managing the context in which functions are executed.

That's all for now. Until next time :)

JavaScript Closures with examples

Aditya Tripathi — Sat, 30 Sep 2023 07:03:18 +0000

In JavaScript, Closure is a phenomena of a code getting executed outside its lexical scope. They happen because of writing lexically structured code.

In other words, Closures let us access a foreign parent scope even after it has exited the runtime. Closures are created every-time we create a scope. They are strongly associated with scopes so before exploring Closures, let us refresh what lexical scopes are.

Lexical Scope

You might be already familiar with the concept of Scope and Execution contexts in JavaScript. If you would like a refresher on these topic, consider a recent article I wrote, similar to this: Mastering JavaScript Scopes

Let's cover the important highlights here briefly.

JavaScript associates important execution details of a program with the place they are declared in the source code, pertaining to the visibility of declared entities. At author time, these are called Scopes. At runtime these become Execution Contexts and are called on Execution Stack one after another to hold the information required for successful execution of the code.

Consider the following example:


function greet(name, typeOfGreeting){

let nameInUpper = name.toUpperCase();

function sayHello(){
 const greetings = `Hello ${nameInUpper} :)`
 return greetings;
}

function sayHi(){
 const greetings = `Hi ${nameInUpper}!` 
 return greetings;
}

return typeOfGreeting === 'hi' ? sayHi : sayHello;
}

In the above example, greet function creates a functional scope. This scope contains two other functions, sayHello and sayHi along with greet arguments and variable nameInUpper.

Note that nested scope can access declared entities of the enclosing scope. This means both sayHello and sayHi can access entities of greet (and Global Scope).

However, a parent scope cannot access entities declared in its nested scopes. So greet doesn't have access to entities declared inside sayHi and sayHello.

Also, note that two greetings variables are created without conflict because they are in separate scopes, i.e. one in sayHi and one in sayHello.

Closures in action

Now that we understand scopes, lets explore how closures "happen" as a result of writing lexically scoped code.

When we execute greet like below:


const greetBen = greet("ben", "hi");

console.log(greetBen()) // Hi BEN!

We notice a rather peculiar behaviour. On executing greetBen we are able to remember entities declared in greet and use them at later point of time in code (i.e. in console.log()), even when greet has completed its execution well before executing greetBen.

This is Closures! greetBen is said to have formed a closure on greet. This allows greetBen to keep the entities declared in greet "alive" (i.e. stop being garbage collected), even after its execution context has been popped out of execution call stack.

For better understanding, consider a slightly modified example below:

const greetBen = greet("ben", "hi");

setTimeOut(() => console.log(greetBen()), 5000)

The above code prints the same output as before but after 5 seconds, re-enforcing our understanding of keeping the entities alive and dynamically accessing a them at runtime even when the scope in which they were declared is not available.

Closure Examples

Now that we have seen some basic examples, let us discuss a couple of advanced ones.

Consider the following code:

(function iife1(a) {
  return (function iife2(b) {
    console.log(a); // What is logged?
  })(1);
})(100);

After a good look, we recognise that iife2 forms a closure with iife1 and hence has access to a. The output of the program will be 100.

Consider another code-snippet:

for (var i = 0; i < 3; i++) {
  setTimeout(function print() {
    console.log(i); // What is logged?
  }, 1000);
}

Because var declarations do not create block scopes, the closure formed by print on the enclosing scope (i.e. Global Scope) will get the final updated value of i. Hence the above code will print 3, 3, 3.

If we were to replace var with let, then the enclosing scope for print will be for block instead of the Global Scope, as let creates a block scope. On each loop iteration, a new scope will be created and the updated i value will be generated for each new scope, resulting in sustaining each value as the loop iterates. Hence the output would then be 0, 1 and 2.

I have borrowed these examples from an amazing blog by Dimitri Palvutin. You can find more of such examples by visiting his write-up here.

Design Patterns

JavaScript developers have been utilising Closures to create some of the most famous design patterns in the language. Some of them are discussed below:

Functions as first class citizens

We are able to pass around functions in JavaScript due to closures. A function as argument forms the closure with the calling function.


function doMath(value, operation){
  return operation(value)
}

function addFive(number){
  return number + 5;
}

function multiplyFive(number){
  return number * 5;
}

console.log(doMath(5, addFive)); // 10

console.log(doMath(5, multiplyFive)); // 25

Here, operation function is able to form a closure with doMath enabling us to operate on doMath argument. It is using this behaviour, we are able to implement callbacks and event-listeners in the language.

Module Pattern

Closures are utilised to create data encapsulation and data abstraction. Consider the example below:

function CounterModule(){

// Data Encapsulation
let counter = 0;

function reset(){
 counter = 0
}

function increment(){
 counter++;
}

function decrement(){
 counter--;
}

function getCounter(){
  return counter;
}

return {
  reset,
  increment,
  decrement,
  getCounter
}

}


// Data Abstraction
let {reset, increment, decrement, getCounter} = CounterModule();

}

In the example above, we created a CounterModule with a private implementation detail counter. We then define operations allowed to be performed on this private data by using functions like reset, increment and decrement because these function form closure with CounterModule.

Thats all what Closures are!

I hope that this article helped you understand Closures and how it is utilised in everyday JavaScript code to implement some of the most important language behaviours and characteristics.

Until next time. Happy Hacking! :)

Mastering Scopes in JavaScript

Aditya Tripathi — Sun, 10 Sep 2023 09:25:29 +0000

In this article, I aim to provide in-depth explanation for Scope and related concepts like scope-lookups, hoisting and scope-chaining, etc in JavaScript.

Before we begin, it is important to understand the technical foundation of the language, most notably, the JIT-compiled nature. I already wrote some articles on topics: A technical introduction to JavaScript and JavaScript runtime and code lifecycle which you can checkout. Also, note that we are going to take a bottom up approach for understanding the concepts. Hence first we will walk through (briefly), a sample code life-cycle and then try to understand the concepts. With that said, lets get started!

As JavaScript is a JIT-compiled, it goes through two steps before finally getting executed: The Compilation Step (or Creation Phase) where the source code is turned into a non-executable intermediate code called byte-code and then The Interpretation Step (or Execution Phase) where the byte-code is converted to machine-code for execution.

Below we will walk through these two processes using some sample examples. They are already covered in depth in the articles mentioned above.

JavaScript Compilation: Creation Phase

When JavaScript code is in it's compilation step it creates an Abstract Syntax tree (AST) using tokens. When the AST is being created, it contains empty objects for identifiers or variables, instead of the value contained by them. Below is an estimated AST diagram for a sample code:

In the above diagram, the proxy represents the empty objects. As we will see, these proxy objects are later replaced with identifier's memory reference.

Along with AST creation, the compilation process also creates Environment Records, also referred as just environments. Environment Record is a specification type, an object like structure containing key-value pairs. These environment records hold information regarding identifier bindings, with some other meta data. Most importantly, they contain identifier's memory reference, which is later used to fetch the value contained in it. It also contains an outer variable, pointing to other environment record. This extra information is used for creating scope chains. We will explore them later in the article.

There are many types of environment records.A Lexical Environment is an environment record which represents lexically written code. For our use-case we are going to use the terms environment record and lexical environments interchangeably.

As we can see from the diagram above, there are two types of environments created: Global and Local. A Global environment is always created when the code execution is started. Local environments are created when compiler encounter code-blocks in the code. Code-blocks are code snippets inside curly braces ({...}).

However, not every code block encountered by the compiler creates a lexical environment. These are only created under certain conditions, like when the compiler encounters a code-block associated with a function declaration or a code-block containing let or const variable declarations or for a code-block associated with catch construct, etc...

To summarise, an environment record is created for code-blocks under certain conditions. Whenever these environments are created the identifier information is stored in these environments.

Environment Record is a specification type, meaning it represent an abstract concept in the ECMA-262 specification and is hard to accurately represent as vendors are free to implement them as they like provided their behaviour remains unchanged. For more information on environment records, refer to this document of the specification.

Once the compiler has a finished generating AST and all the relevant environment records for the code, the next step in compilation process is to start generating byte-code using the information present in environment records. This step is also called parsing.

In parsing, the AST is traversed, node-by-node, and byte-code is generated by filling the proxy object in AST, with identifier's memory reference (and not its value) by referring the corresponding environment record (a lookup). These identifier references are later used for resolving actual values held by identifiers in execution phase (another lookup).

Once the byte-code is generated, the creation phase ends and the execution phase begins.

JavaScript Interpretation: Execution Phase

The byte-code is given as input to the interpreter which is responsible for the execution, i.e. converting the platform independent byte-code to platform dependent machine-code (0s and 1s). This is where Execution Contexts come into picture.

Similar to lexical environment, Execution Context is an abstract concept (again, a specification type) used to track the execution of a JavaScript program. We can define Execution Context as a "runtime form" of lexical environment with some extra information to execute a JavaScript code successfully. Each execution context contains the following:

A lexical environment
Value of this

When a chunk of byte-code is being interpreted/executed to machine-code, the corresponding execution context (i.e. a lexical environment and this binding information) is pushed onto a stack data-structure called Execution Context Stack, otherwise called as call-stack. The execution context on top of this stack is called a running execution context, because it represents the code being run at the current moment of time. For each running execution context the interpreter start performing lookups for values, contained in identifier references (added in the byte-code previously).

In the diagram above, the blocks highlighted with orange represent how execution contexts are used to fetch runtime values required to executed the program. The highlighted block in top of call-stack is represents running execution context.
The JS interpreter fetches the value using identifier's memory reference. The byte-code is then interpreted to machine-code and the code is finally executed.

Now that we understand both the phases we are ready to explore JavaScript Scopes and different terminologies associated with it.

We are going to dissect the following sample code:

var c = 10;
function foo(a){
 if(a === 10){
  let b = 20;
  console.log(b,d);
 }else{
  var e = 20;
  console.log(e,c)
 }
  var d = 100;
}
foo(c);

Scopes

When we run the above code, the first step it goes through is compilation. We already know that in compilation, AST and lexical environments are generated.
Scope refer to the visibility of an identifier in a particular code-block (or in specification terms, a lexical environment). From this perspective, Scopes are nothing but a static representation of lexical environments.
We also discussed that lexical environments are created for code-blocks with some rules, let discuss two most important conditions where scopes are generated by the compiler.

Compiler creates a new scope for a code-block which contains at-least one let and const declaration or when a code-block is associated with a function declaration.
A code-block with let or const declaration gets its own scope (lexical environment), hence we say let and const are block scoped, but if we use var, the identifiers are associated with the most recent 'outer' functional lexical environment. Hence var is always functionally scoped.

The following diagram represents the creation of scopes for different identifiers for our sample code above. Note that I have intentionally left the outer field empty. We will come back to this when exploring scope chaining:

c and foo are created in Global Lexical Environment (Global Scope), represented in blue.
Because foo is a function a new lexical environment is created for the code block associated with it, represented in green. This contains a, d and e but not b.
For the if statement, a new lexical environment is created because it is associated with a code-block containing a let declaration (block scoped). Hence, b is present inside this lexical environment instead of foo's, represented by purple. Note that this is not true for else because it doesn't contain any let or const declared variables.

That's all what scopes are. A word which represents the visibility of an identifier in the code or a representation of static lexical environments.

Hoisting

Before defining hoisting, let us understand the memory allocation process used by JavaScript as it plays a crucial role in the definition.

In compilation phase, identifiers are allocated memory, however not every identifier is treated the same. Identifiers associated with function and var declarations are allocated memory and are initialised. Identifiers associated with let and const are allocated memory but are not initialised with any value. They are said to be allocated in a Temporal Dead Zone or TDZ. Because there is no initialisation for these variables, they cannot be 'accessed' before they are initialised.

function declarations are straight away initialised to the associated code-block. var are initialised with undefined. For example in our sample code var c is initialised with 10 but compiler anyway initialises it with undefined once and while execution, when interpreter gets to the line var c = 10 it is re-assigned to 10.

Because of this behaviour var variables are accessible in the statements with a value of undefined even before their actual declaration or assignment happens in the code.

console.log(msg)  // undefined
var msg = 'Hello World'; //undefined replaced with 'Hello World'

With this understanding, let us define Hoisting.

Hoisting is a phenomena to use an identifier before declaring it, causing side-effects in the program. Note that the definition is generally opinionated but the above provided definition is quite generic and should work for most of the opinions.
Newer constructs like let and const are hoisted but not initialised with a value and hence cannot be accessed before they are declared.
var identifiers are hoisted and initialised with undefined value.
Identifiers associated with function declarations are also hoisted, but are not initialised with undefined, instead they are assigned the code-block represented by the function declaration.

In English language, hoisting means lifting objects with ropes and pulleys. But JavaScript doesn't actually lift or pull any variables or functions up in the code-structure, contrary to what we generally read about hoisting. No declaration is 'moved' on top of scope or in-fact anywhere. It is just a naive way (and misleading) of explaining the concept.

Hoisting happens per scope (lexical environment), so for any code-block whose lexical environment is being created, the block is first 'scanned' for all the declarations and all variable declarations are allocated some memory. undefined is assigned to identifiers declared using var. let and const declared identifiers are placed in a TDZ instead, without any initialisation.

Now that we understand hoisting, let us understand a hoisting scenario in our sample code. When we run the sample code:

var c = 10;
function foo(a){
 if(a === 10){
  let b = 20;
  console.log(b,d);  // 20 undefined
 }else{
  var e = 20;
  console.log(e,c)
 }
  var d = 100;
}
foo(c);

d is hoisted and initialised with a value of undefined for foo's lexical environment (scope), and hence prints undefined because when d was accessed in console.log it hasn't been re-initialised with 100.

Scope Lookups and Scope Chains

Whenever a JavaScript code is compiled and executed, a global scope is always created. Remember that execution contexts are nothing but lexical environments (scope) with some extra information (this binding) and resolved identifier values instead of identifier references.

There are two types of lookups performed by JavaScript. The first one happens at compile time, which looks up identifier name against a memory reference to check what memory reference is allocated to the corresponding identifier name. The second look up happens at runtime, where these memory references are resolved for the actual values they contain.

Lets try to elaborate on this with our sample code example:

A LHS lookup happens in creation phase (or compile time), when we lookup for an identifier memory reference against its name (c, b, d ...etc). The proxy objects in AST are replaced with these memory references in byte-code, fetched after a successful lookup.

A RHS lookup happens in execution phase, when we want to resolve an memory reference of an identifier (which was looked up in the above step) for the actual value contained by that identifier (10, 20, 100 ...etc).

An unsuccessful lookup results in ReferenceError in strict mode, because it means the name of the variable we are looking for has never have been declared in any lexical environment of the code. In non-strict mode, unsuccessful LHS lookup will automatically create a var variable with the name of identifier being looked up.


// strict mode

let a = 10;
console.log(a) // 10
console.log(b) // lookup fails for `b`, ReferenceError

To understand the concept better, lets take some examples of LHS and RHS lookups from our sample code.

var c = 10 will result in a LHS lookup for c. When foo(c) or console.log(e,c) is called with c as argument (assuming the else block executes), a RHS lookup will happen to pass the copy of the value contained in c as function argument to foo or console.log.

Similarly, let b = 20 will trigger a LHS lookup, console.log(b,c) will result in a RHS lookup.

To summarise, LHS lookups 'checks' for memory references against identifier names. A RHS lookup 'checks' for the value contained in a memory reference, already verified by LHS lookup.

A rather simpler (but naive, and sometimes confusing) way to understand these lookup are these:
LHS lookup is also called Left Hand Side lookup and RHS, Right Hand Side, because LHS happens for resolving identifier lookups on 'left-hand' of a statement (i.e while initialisation or re-initialisation) while RHS happens when identifiers are on the right-hand side (when we actually use that variable).

Now that we have discussed lookups, let us talk about Scope Chains. We established that in creation phase, JavaScript compiler creates lexical environments, which are just a static representation of scope.
While creating lexical environments, the compiler associates different lexical environments with each other using the outer variable.
This association is based on nesting structure of code-blocks in the code-structure. For eg. foo's lexical environment will have an outer variable pointing to the Global Lexical Environment. Similarly, the if's lexical environment's outer variable will point to foo's lexical environment. We will now complete our diagram by filling the value of outer:

This association of lexical environments (or scopes) help JavaScript interpreter travel through different scopes when a lookup is not successful in the current scope using the outer reference.

For example, in our sample code, if we run call foo(c),
when the interpreter reaches console.log(b, d), it tries to resolve for d in the if's block scope. The lookup returns unsuccessful because d is not defined there. It will then try to look into outer lexical environment using the outer field of if's lexical environment, which is pointing to foo's lexical environment, because if block is nested inside foo. It finds it there and returns with a successful lookup.

Hence, scope chaining refers to a concept which represent accessible nested scopes of a JavaScript program as a result of writing lexically scoped code, which is utilised to resolve identifiers in a foreign scope, if the identifier is not resolved in the current scope.

Shadowing

Shadowing refers to an event where the JavaScript engine resolves the value of a locally scoped identifier with same name as identifier in a foreign or outer scope. For example:

let message = 'Hello Global!'

function printMessage(){
  let message = 'Hello Local!'
  console.log(message)

}

printMessage(); // Hello Local!

The message local to the scope of printMessage function has said to have shadowed message in global scope.

Conclusion

Lexical environments, scopes and execution contexts advocate similar ideas at different time-period of the program. There is no such term as Scope in ECMA specification. Scope is a passed around term generally meant for visibility of the identifier inside a code-block. However lexical environments and execution contexts are specification types. In a very generic sense, lexical environments are static representation of scope, while execution contexts are runtime representation of scope.

Until next time, happy hacking :)

JavaScript Runtime and Code Lifecycle

Aditya Tripathi — Thu, 17 Aug 2023 09:10:44 +0000

In this article we will explore all the important aspects of JavaScript's runtime. Our aim is to understand the general inner workings of JavaScript's runtime, covering all the important details. Let's delve in!

Architecture Overview

JavaScript is a dynamic, single-threaded, JIT compiled, stack-oriented programming language. I have covered technical details of the language, in my other article: Technical introduction to JavaScript. It is important to understand these aspects beforehand to get the most of this article.

Lets start with a general architectural diagram of the browser runtime:

In the above diagram, the colourful part is the core JavaScript. Everything else is the environment which is responsible to provide a platform to run JavaScript code successfully.

Anytime we are running a JavaScript code, we are running it in some kind of environment, which is not a part of the language specification. A JavaScript Environment is a system that facilitates JavaScript code execution using an engine and extends JavaScript's functionality by providing different functions and APIs. For eg:

NodeJS is a JavaScript environment which use a JavaScript engine called V8 and provide APIs to create HTTP servers, handle file management and much more.
Chromium based browsers (like Google Chrome) are JavaScript environments which use V8 engine, same as NodeJS, and provide Web APIs (document, window, etc) to perform front-end specific task for creating powerful dynamic websites.

Other famous browsers have their own implementations of Web APIs and engines. For eg. Microsoft's Edge uses Chakra, Mozilla's Firefox uses SpiderMonkey, etc.

Some IoT platforms use Duktape and JerryScript as their engines.

JavaScript Code Execution

JavaScript is a single-threaded language, which means it can only execute one task at a time. When a program is executed, the function being executed are called one by one for the execution. To keep track of the execution status and function calls, JavaScript utilise a stack data-structure called call-stack. To understand it better, lets consider an example:




function multiply(x,y){
  return x * y;
}

function square(n){
  return multiply(n, n)
}

let a = 10;

console.log(square(a))

When the above code is run, each function call pushes the function being called into the call-stack. When the function has completed its execution, they are popped from the call-stack.

The above code is executed synchronously, meaning all the execution happens immediately, in one go, at a given point of time, without the control shifting over to some other entity. To contrast, lets modify our example to understand asynchronous code behaviour.

We can develop asynchronous code using JavaScript because of the Event Loop and Call-back Queue, provided by the runtime environment (see the architecture diagram above). These features provided by JavaScript runtimes enable use to write asynchronous code. JavaScript by itself is a blocking synchronous language.

In the code below, we use a function from Web APIs called setTimeout to create asynchronous behaviour. It enables us to call a function (passed as first parameter to setTimeout) after a mentioned time in milliseconds (second parameter) hence making the code asynchronous.



function multiply(x,y){
  return x * y;
}

function square(n){
  return multiply(n, n);
}

let a = 10;

setTimeout(function later(){console.log(square(a))}, 1000);

console.log('Hi')

Upon execution, the function later is send to the call-back queue, to call it back after 1000 milliseconds, or one second. That is why, when we run the code, we first see Hi and then, at least after a second, 100 in the output. When the code is getting interpreted, the asynchronous functions are send to the callback queue. These are pushed to stack once the call-stack is empty, this is done by Event Loop.

By now we have a general idea of how JavaScript runtime works in synchronous and asynchronous operations. If you are interested in further explorations JS 900 is a great tool to explore synchronous and asynchronous language behaviour in-depth.

JavaScript Code Lifecycle

Let us go one level deeper in understanding how the code being executed is transformed end-to-end i.e. starting from source file all the way to generating machine code and executing it.

When we run a JS program in any environment discussed above, it goes to different phases before it is finally executed. These are namely Tokenisation, Parsing, Code-Generation and finally Code-Execution.

Novice developers often claim that JavaScript is an interpreted language, but as we will see below, this is only half-truth.

Any JavaScript program is always tokenised and parsed to generate an intermediate form of code called byte-code which is then interpreted by an Interpreter to generate executable machine code. This is different from purely interpreted languages where source code is directly converted to machine code for execution. (Difference between Byte Code and Machine Code)

A JavaScript program is dynamically compiled to byte-code, before it is interpreted and executed. This is why JavaScript is a 'Just-in-time' (JIT) compiled language. Notice that we used the term dynamically compiled. This is to reflect on the fact that JavaScript Engine doesn't have the luxury to pre-compile JavaScript and run it later (also called static compilation or Ahead-of-Time (AOT) compilation) like other compiled languages. Lets understand this whole jargon step-by-step in detail now. To set the premise, the JavaScript runtime under consideration is V8, used by Chromium based browsers and NodeJS.

We start with a sample JavaScript source code.



var sayHello = 'Hello World!';

function printMessage(message){
    console.log(message)
}

printMessage(sayHello)

The engine starts with locating the source code. Generally, this code will either be on a file, in a Web Server or present in a script embedded in an HTML <script> tag.

Tokenisation

After identification, the source code is tokenised. The process is called tokenisation. During the process, JavaScript engine converts syntactically sound source code into tokens. This is the process where error in syntax are highlighted. In very simple terms, the source code is broken down into smaller valid language constructs. For eg. var sayHello = 'Hello World!'; is broken down into var a keyword to declare functional scope variables, sayHello an identifier, = an operator and 'Hello World' a string literal and finally ; a punctuator.

In some compiled languages, this process is also called lexing.

Parsing

Once the tokens are generated, they are passed to a Parser as input, which performs parsing. Parsing is the process to generate Abstract Syntax Tree (AST) and execution scopes. Generating AST allow us to represent the hierarchal structure of the program. This hierarchy information is used by Interpreter in subsequent steps for generating byte-code.

Notice that AST doesn't directly contain the value of the literals or variables. We will cover this later.

For V8 engine, there are two types of parsing: eager parsing and lazy parsing. The eager parsing generates both AST and execution scopes, while lazy parsing only generates AST.

Execution scopes, in simple terms are places which map identifiers to their assigned value. For our example a is mapped to 10 number literal. This information is stored in execution scopes, instead of directly putting them in AST, to keep the AST generation a fast process.

Eager parsing is used for top level code, which will be executed immediately by the Interpreter while lazy parsing is for the nested code and declarations which are not called and hence are not required for the execution of the program yet.



var sayHello = 'Hello World!'; // eagerly parsed

// eagerly parsed, but everything inside is lazy parsed for now
function printMessage(message){ 
    console.log(message)
}

// oh shit, need to parse everything eagerly inside, as the function is called.
printMessage(sayHello)

In eager parsing, the generated execution scopes are used to assign identifier values to variable proxies inside AST (as mentioned in the diagram above), which did not have any values assigned to them while AST generation. Lazy parsed AST are left without assigning the identifier values so that they are created faster and hence speed up the parsing process. The process of assigning identifier value from execution scopes to variable proxies in AST is referred to as Scope Analysis.

Lazy parsing is performed by a pre-parser according to the V8 terminology. Pre-parsers are twice as fast as Parsers because they skip execution scope generation and value assignments.

Code-Generation & Execution

Once the AST is generated and hydrated (variables proxies assigned with values), it is passed to a Byte-code Generator. It is responsible for producing a stream of byte-code, one byte-code at a time. Once the byte-code is generated, it is finally interpreted by an Interpreter to produce machine Code (0s and 1s). The machine code is then executed to produce the program output.

A word on Javascript Optimisations

As a side note, it is a good option to discuss some techniques like inline caching adopted by JavaScript engines to speed up the code compilation and execution process. JavaScript engines are capable of optimising code runs when a piece of code is being run multiple times.

As we have already discussed above, once the hydrated AST is fed to an Interpreter, it starts generating a stream of byte-code. While it is doing this, the output stream is passed to an 'optimising compiler' which is responsible for producing an optimised version of machine code, depending on what information it has from previous execution runs. Below is a very generic diagram of the process. The whole process is referred to as execution & optimisation pipeline.

When the Interpreter is generating byte-code, it also stores some sort of profiling data, which can be used in subsequent runs. When a function becomes 'hot' (i.e. when it has been run multiple times), the byte-code generated for that function, along with the profiling data is passed to the optimising compiler to create 'inline cache' for that function, which on future runs, are directly swapped in the byte-code stream instead of regenerating the byte-code.

Some engines have multiple optimising compilers instead of just one. Essentially all optimisations and caching techniques function on the fact that JavaScript engine is able to 'profile' the Object Shape (everything non-primitive in JavaScript is an Object). The article: JavaScript Shapes and Inline Caches explains the whole optimisation process in detail.

Conclusion

Our journey into JavaScript's runtime has unveiled its core mechanics, from architecture to code execution and lifecycle. We've grasped its dynamic, single-threaded nature, role of environments, and execution contexts. Understanding both synchronous and asynchronous code execution, the event loop's role, and diving into the lifecycle from source to machine code, we've unraveled JavaScript's essence as a "Just-in-time" compiled language. Further, optimisation techniques like inline caching have been explored, showcasing the intricate strategies boosting performance.

Until next time :)

A technical introduction to JavaScript

Aditya Tripathi — Sun, 30 Jul 2023 11:06:38 +0000

In this article, my goal is to offer an easily understandable technical overview of the JavaScript language, tailored for entry-level developers. I will cover a range of general technical aspects of JavaScript, providing insights into its key concepts and features. Additionally, I will include plenty of helpful resources for readers to delve deeper into the language without the hassle of searching extensively for reliable articles.

TLDR;

JavaScript is a high-level, dynamic, single-threaded language which is stack-oriented and JIT compiled.
Abbreviated as JS, it was created in 1995 to introduce interactivity to static web pages.
JavaScript adheres to the ECMAScript standard, specified in the standard ECMA-262.
JavaScript consists of two types of constructs: Primitives and Non-Primitives.
JavaScript is always pass-by-value language and treats functions as first-class citizens.
The utility of JavaScript's Primitives can be extended through Primitive Wrappers. This is achieved by invoking a Constructor function with the primitive as its argument.

The high level intro

JavaScript has been a foundational technology since the introduction of the World Wide Web. It was created by Brendan Eich in 1995. Over the years, JS has evolved significantly, transforming from a language that made static HTML content interactive to a powerful cornerstone of modern-day web applications.

To appeal to developers at that time, JavaScript drew inspiration from languages like C and Lisp. Apart from being a high-level, single-threaded language it is Just-In-Time compiled (JIT) and dynamically typed.

The specification

JavaScript conforms to a set of specification created and maintained by an organisation called European Computer Manufacturers Association, ECMA. Apart from creating computer language specifications, ECMA is involved in standardising various areas, such as multimedia communications and electronic equipment safety. Each specification they produce is assigned a reference number or a code.

The specification code followed by JavaScript is ECMA-262. It defines a general-purpose, vendor-neutral scripting language called ECMAScript. You can find the latest draft of the standard here. In essence, ECMAScript serves as the blueprint for JavaScript.

So, if someone mentions that ECMAScript is the same as JavaScript, correct them:

ECMAScript refers to the standard described in the ECMA-262 specification. JavaScript is a language that conforms to this standard, with some variations, which we will discuss below.

For more detailed information on the relationship between ECMAScript and JavaScript evolution, you can read this article.

Before discussing the variations, let's mention an important group called TC39, which is part of ECMA.

TC39 is a group of developers and academics which is responsible for understanding the specification and evolving JavaScript, conforming to the sepcification. If you had trouble with different versions of JavaScript like ES6, ES5, ES3 etc, you now know who to blame.

Regarding variations from the specification, JavaScript incorporates a handful of features not mentioned in ECMA-262 (like ArrayBuffers). These intricate details further differentiate ECMAScript from JavaScript.

That covers the general overview about specifications. Now, let's delve into some implementation details of the language.

JavaScript General Characteristics

Before starting development with JavaScript, it's essential to understand its general characteristics.

Primitives, Non-Primitives and Primitive Wrappers

In JavaScript, everything is categorised as either a Primitive type or a Non-Primitive type (i.e. Objects).

Primitives are immutable and single valued.
Non-Primitives, on the other hand, are objects.

There are seven primitive types in the language:

number
bigInt
string
boolean
null
undefined
Symbol

On the other hand, constructs like functions and arrays are a special type of object and hence are classified as Non-Primitves. It is safe to assume that any language construct that is not a Primitive is classified as an object.

Constructors and Primitive Wrappers

While working with JavaScript, you might come across built-in constructor functions that resemble the names of Primitives. These are: String(), Number() and Boolean().


const aString = 'What am I?'
const aStringObject = new String(aString);

console.log(typeof aString);  //string
console.log(typeof aStringObject);  //object

The motivation behind having a constructor function for primitive values is to extend the functionality of a primitive. Primitives are single immutable values, while non-primitives are objects, so they can have different attributes and functions assigned to them. This feature allows us to add utility to a primitive, essentially extending its ability.

In the example above, when we use a constructor function on a primitive, it enables us to use certain methods on the value defined in the String object. The constructor function (String()) wraps the primitive into a String object, becoming a Primitive Wrapper. This object contains functions like toUpperCase(), toLowerCase(), charAt(), etc., which can now be used on the wrapped primitive value directly.

aStringObject.toUpperCase(); // WHAT AM I?

Meanwhile, you may also notice that we can use methods available in the String object on a primitive value without explicitly wrapping it in a Constructor, as shown below:


aString.toLowerCase() // what am i?

This is because JavaScript implicitly wraps the String object whenever it notices that we are trying to access one of the functions present in the Wrapper. This process of automatic implicit type conversion is called Coercion. You can explore more about it here

Function as first class citizen

The concept of first-class and second-class citizens originated with Algol.

Although not strictly defined at that time, a first-class citizen is generally something that supports all types of available operations on itself. This includes being passed as arguments, returned from a function, and assigned to a variable.

In JavaScript function behave as first-class citizens because all the functions are a variation of JavaScript objects, which as we have studied are building blocks of the language along with Primitives. Learn more about first-class functions here

The Runtime Environment Overview

When we execute JavaScript code, it goes through a runtime process involving several entities. To understand the end-to-end execution process, we'll take a top-down approach to break it down step-by-step. This means we start from a file with .js extension containing some JavaScript code.

The JavaScript code is executed as follows, steps ordered chronologically:

Identifying the source code The runtime identifies the source code in the .js file. For simplicity, we assume there are no syntactical errors in the source code.
Tokenization (Lexing) The source code is tokenized, a process known as tokenization or lexing. This breaks the code into smaller units called tokens.
Abstract Syntax Tree Generation The tokenized code is used to generate the Abstract Syntax Tree (AST) which represents the structure of the code. This process is called as parsing.
Code Generation The generated AST is used to create executables, sometimes referred to as byte-code. This step is known as code generation.

This is just a high level explanation of the JavaScript code lifecycle. For in-depth exploration, checkout this article, after you have read the overview. It will take you to the abyss.

Finally, the byte-code is translated into machine code, with platform-dependent optimisations, and executed to produce the required results.

The following picture summarises the process:

Conclusion

In this article, I have covered essential topics that provide a strong technical foundation for those who are new to learning the JavaScript language. If you're starting to learn JavaScript, these topics will give you a better perspective on the language.

For more insights into JavaScript technicalities, I highly recommend checking out this resource beautifully summarised by Tony Stubblebine which served as my inspiration for writing this article. I've made sure that the content of both articles is unique to offer the readers the most value.

Thank you for taking the time to read my article! I would greatly appreciate your suggestions and feedback in the comments below, as it will help me further improve the content for the readers.

Happy Coding!

DEV Community: Aditya Tripathi

Javascript "this" binding with examples

Bindings

Implicit Binding

Explicit Binding

new Binding

Arrow Functions

JavaScript Closures with examples

Lexical Scope

Closures in action

Closure Examples

Design Patterns

Mastering Scopes in JavaScript

JavaScript Compilation: Creation Phase

JavaScript Interpretation: Execution Phase

Scopes

Hoisting

Scope Lookups and Scope Chains

Shadowing

Conclusion

JavaScript Runtime and Code Lifecycle

Architecture Overview

JavaScript Code Execution

JavaScript Code Lifecycle

Tokenisation

Parsing

Code-Generation & Execution

A word on Javascript Optimisations

Conclusion

A technical introduction to JavaScript

TLDR;

The high level intro

The specification

JavaScript General Characteristics

Primitives, Non-Primitives and Primitive Wrappers

Constructors and Primitive Wrappers

Function as first class citizen

The Runtime Environment Overview

Conclusion

`new` Binding