DEV Community: Lalit Aditya

Prototypical Inheritance in JavaScript

Lalit Aditya — Tue, 31 Mar 2026 14:20:56 +0000

Prototypical inheritance is one of the core concepts in JavaScript.

But at the same time it is considered as one of the tough topics to understand. Even the experienced JS developers fall short in confidence while dealing with inheritance/prototypical inheritance in JS.

But to be honest, prototypical inheritance doesn't have any room for ambiguity, and it's pretty straightforward to understand.

In this post, I will deep dive into the core concepts of JS related to prototype. What exactly is a prototype? What is the role of the new keyword in prototypical inheritance, and why is this inheritance called prototypical inheritance? Internal working and ES6 updates regarding prototypical inheritance.

The Confusion
new keyword and its role in prototypical inheritance
Objects in JS
Inheritance chain (instance and static)
ES6 updates

The Confusion:

The biggest confusion that almost everyone faces while trying to understand the prototypical inheritance is the word prototype itself.

Because this is actually confusing, as per the ECMA docs, the word prototype is used in two different places, and that too, to represent two different entities altogether

One is the [[prototype]], and the other is the property named prototype
Now let's settle the dust.
1. [[prototype]] refers to the __proto__ property. Every object in JavaScript has a default, built-in property named __proto__. And the same __proto__ property represents the [[prototype]] mentioned in the docs. For the sake of simplicity, in this post, whenever I want to refer to this [[prototype]], I will always refer to it as __proto__.
2. The property named prototype - In JavaScript, every function created by default has a property named prototype attached to its object. (Yes, a function is also an object in JavaScript, but a special kind of object; we will discuss the specialty of this object later in this post.)
Think of it like a function is an object, and it has a key named prototype on it. We didn't add this key to the function object; it's present by default. And the value of this key is again an object.

So a function object in JS has 2 properties by default.
One is __proto__ because a function is also an object, and every object has __proto__
And the other is prototype because it's a function.

In simple terms, only function objects get access to a special default key named prototype along with __proto__

This might sound confusing; let's take an example

function add(a, b) {
  return a+b
}

When the JS engine sees this instruction, it actually creates an object in the background. And since this object is a function object, as discussed, it will have a default property added to it named prototype

Something like this:

{
  name: add, // name of the function
  length: 2, // referring to 2 parameters the function add has
  prototype: { // this key is added by default as add is a function
     // .... (some default key-value pairs would be present, we will see them later)
     __proto__:Object.prototype // wait what ? what is this ? 
  }
  __proto__: Function.prototype // again wait what ? what is this ?
}

NOTE:

Wherever we see an object ({}), we see a __proto__ being present, because every object in JS has a __proto__ property

Now, add is just a reference to this object present in memory, and using add we can access this object.

For example, we can add custom key-value pairs to this object.

add.myCustomKey = 10;
add.myCustomFn = function() { console.log('Add custom function') }
console.log(add.myCustomKey) // 10
add.myCustomFn();  // Add custom function

NOTE:

If you observed, there were a couple of places where __proto__ was used above in the function object, and we had no idea why at one place Object.prototype is present and why at the other place Function.prototype is present. And that's completely fine. We will clear up this confusion in the coming sections.

To summarize, every object in JavaScript has a built-in property named __proto__ and since a function is also an object in JavaScript, even the function object also has a __proto__ property, but as discussed, since a function is a special object, apart from the built-in __proto__ property, it also has one more special property named prototype, which is again an object.

Mental Model:

If object, then has access to the __proto__ property.
If the object is a function object, then it has access to the __proto__ and prototype properties.

let obj = {}
function add(a, b) {
  return a+b;
}
console.log(obj.__proto__) // available
console.log(add.__proto__) // available
console.log(add.prototype) // available because add is a function
console.log(add.prototype.__proto__) // avaialbe, because prototype itself is an object, and every object has __proto__ property
// All these properties are present by deafult. Added by langugage

So from now on in this post, when __proto__ is referred to, we are talking about the default property present in every object, and when prototype is referred to, we are talking about the default property present in a function object.

new keyword and its role in prototypical inheritance:

The new keyword in JavaScript is used to create an object.
Syntax: new fn()

Here, fn refers to a function or a constructor function, and the new keyword must be used with a function; otherwise, it results in an error.
But most importantly in this process of object creation, it also sets the __proto__ property of the newly created object.
We still don't know what exactly this __proto__ property is. But we learned the fact that it exists by default on every object. We will see what exactly this __proto__ is in the next section
Internal working of new:
When new fn() is executed, there are some predefined sets of activities that it performs. They are:

Create a brand new object
Bind this to the newly created object.
Set the __proto__ of the newly created object to fn's prototype.
Run the function and return the newly created object (implicit return) if no explicit return is mentioned in fn.

Let's understand it by an example.

function User(name, age) {
    this.name = name;
    this.age = age;
}
const u = new User("Peter", 25);
console.log(u);

Now let's try to simulate the work done by the new keyword.

So think of something like below. (Not exactly, but more of a pseudocode)

function User(name, age) {
    // const obj = {}; // 1. creation of a new object
    // this = obj     // 2. binding this to new object created
    // this.__proto__ = User.prototype // 3. sets the newly created object __proto__ to User.prototype
    this.name = name;
    this.age = age;
    // return this;  // 4. implict return added, new object returned
}

So, as we can see, the new keyword plays an important role by not only creating a new object but also setting the created object's __proto__ property.

We will see the significance of this step in the next section and how this step lays out the foundation for prototypical inheritance

Now I assume there shouldn't be any doubt/confusion in User.prototype. Since User is a function object, it will have access to a property named prototype.

console.log(User.prototype) // {}

Objects in JS:

In the previous 2 sections, we learned that every object in JavaScript has access to an inbuilt property named __proto__ and if the object is a function object, then along with __proto__ it will also have access to prototype

But what exactly are these predefined properties? What values do these properties hold? What's their significance?

Let's try to answer that.
In simple terms, __proto__ defines where JavaScript should continue looking when a property is not found on an object itself.

When you try to access something on an object and it doesn’t exist there, JavaScript follows the __proto__ link to another object and continues the search.

And that's it; that's the whole purpose of __proto__ in JS.
But since __proto__ is a default, built-in property present in every object, it also has a default value, and it is Object.prototype.

But now what is this Object.prototype ?
Before answering it, let's look at a few examples

const n = new Number(10);
const s = new String('Peter');
const p = new Promise((resolve) => resolve({data: 'success'}));
function User(name, age) {
  this.name = name;
  this.age = age;
}
const u = new User('Peter', 25);

Exercise: Try to perform all 4 activities done by the new keyword.

- Were you able to find any common observation? I think from the above code snippet, the easiest instruction to understand would be const u = new User('Peter', 25), as we clearly discussed this case while we were trying to understand the new keyword

- Here, "User" is a function or, more specifically, a constructor function since it is invoked via the new keyword. Hey, but wait, we also learned that the syntax of the new keyword is new fn(), where fn is a function

- Then how are we able to do new Number(10), new String('Peter'), new Promise((resolve) => resolve({data: 'success'}))? Why does the new keyword work here?

- The idea is actually simple: it works because, under the hood, all of these are constructor functions. In fact, every built-in type you use—Number, String, Promise, Boolean, Array and others—is essentially a predefined constructor function provided by the language itself. And hence the new keyword works.

We can check this by the following:

console.log(typeof Number);  // function
console.log(typeof String);  // function
console.log(typeof Promise); // function
console.log(typeof User);    // function

Now the two most important built-in types provided by the language are Object and Function. And these are constructor functions.

From previous sections, we learned that every function object will have a built-in property named prototype.

Hence we can do the below

console.log(typeof Object)    // function
console.log(typeof Function)  // function
console.log(Object.prototype)  // {}  
console.log(Function.prototype) // {}

Object.prototype and Function.prototype aren't actually empty objects; why we see empty objects is because all the properties of Object.prototype and Function.prototype are non-enumerable, hence the console.log doesn't show them

But we can check the properties of these objects by the following:

console.log(Object.getOwnPropertyDescriptors(Object.prototype)
console.log(Object.getOwnPropertyDescriptors(Function.prototype)

The above instructions give all the properties present in the Object and Function predefined functions.

Now let's get back to the default value of __proto__,. As discussed, the default value is Object.prototype

Meaning, if the property being searched for isn't present in the object, continue the search in Object.prototype, because that's what is present in __proto__. For ex:

const obj = {};
console.log(obj.__proto__ === Object.prototype) // true
console.log(obj.toString()) // '[object Object]'

But wait, in the above code snippet, I never defined any property named toString on my obj, but still somehow we can access the toString property

And what we just discovered is the prototypical inheritance in JS

Let's dissect the flow

When we tried to access toString on obj, the JS engine first searched toString on obj. Since toString wasn't present in obj, the JS engine checked the __proto__ of obj, it had the value of Objet.prototype, so now the JS engine continued the search in Obect.prototype. In Object.prototype, we find the key toString whose value is a function, and invoking it gave us the result '[object Object]'

NOTE:

What if toString didn’t exist on Object.prototype? The idea is straightforward: JavaScript would continue the lookup using the same mechanism—by following the __proto__ chain. It would check the __proto__ of Object.prototype and keep searching upward.

__proto__ property would be present in Object.prototype as Object.prototype is an object, and every object in JS will have a __proto__ property

The catch, however, is that __proto__ on Object.prototype is null, which signals the end of the prototype chain—there’s nowhere further to look, so the search stops there.

So from the above discussion, we understand a couple of things.

1. The default value of __proto__ in any object is Object.prototype.

2. The lookup stops if the property isn’t found on Object.prototype, because its __proto__ is null—signaling the end of the prototype chain.
Let's take one more example to understand:

const obj = {}
console.log(obj.name) // undefined
Object.prototype.name = 'Parker'
console.log(obj.name) // Parker

- The above example should clear up how the lookup chain works. Let's try to simulate the JS engine.

- obj is an object, and hence it will have a default built-in property named __proto__ with value Object.prototype

- Upon accessing obj.name, search a property named name on obj. If found, return the value; else, continue the search by checking the value of the __proto__ property of obj.

- Since the name property was not found on obj, continue the search in Object.prototype (because that's what is present in obj.__proto__)

- Check for the name property on Object.prototype, if not found, continue the search by checking the value of the __proto__ property inside Object.prototype. The value found is null, meaning stop the lookup chain and return undefined

- But after the first console.log, we are doing something interesting; we are actually adding a property in Object.prototype. So the Object.property should look something like this

- Hence in the 2nd time lookup, we actually get a value of Parker as this time it is found in Object.prototype

Now let's discuss the most interesting part. Remember, in the earlier sections, we said that functions are also objects in JS, but they are a special kind of object. But why is that?

We learned a rule that every object in JS will have a __proto__ property, and its value will be Object.prototype. But this isn't true in the case of function objects.

For every function object (either custom or predefined), __proto__ is equal to Function.prototype. This can be easily checked as follows.

function wish() {
   console.log('Hi');
}
console.log(wish.__proto__ === Function.prototype)     // true
console.log(wish.__proto__ === Object.prototype)       // false
console.log(Number.__proto__ === Function.prototype)   // true
console.log(Promise.__proto__ === Function.prototype)  // true
console.log(Function.__proto__ === Function.prototype) // true
console.log(Object.__proto__ === Function.prototype)   // true

// the last 2 cases are also true, because Function, Object are also functions in JS. This can be checked using typeof operator

Now this should also explain why call, apply, and bind functions can be invoked on every function in JS.

The reason is they exist in Function.prototype

console.log(Object.getOwnPropertyDescriptors(Function.prototype)) // call, apply, bind are properites inside Function.prototype

Let's understand by taking one more example:

function wish() {
   console.log(`${this.name} says Hi`);
}
let obj1 = { name: 'Peter' };
wish.call(obj1);

- Let's again try to simulate the JS engine when wish.call(obj1) is invoked.

- We know the function wish creates an object, and wish is a reference to the object.

- When a property named call is accessed on wish, first the property call is searched in the object referred to by wish. It isn't present, so continue the search by checking the __proto__ of the object referred to by wish.

- Since wish is a function object, its __proto__ has the value Function.prototype, so the lookup is continued in Function.prototype
- In Function.prototype, we find the property call which is a function, and hence the wish.call is executed.

The final mental model:

1. If an object then has access to the __proto__ property whose value is Ojbect.prototype

2. If the object is a function object, then it has access to the __proto__ property and prototype property, and the value of __proto__ is Function.prototype.

Observations:

Since wish,Function, and Object are functions (wish being custom-defined and Function, Object being predefined), they have access to both __proto__ and prototype properties, whereas obj is just a normal object and hence has access to only the __proto__ property.
Every function object's __proto__ is Function.prototype and normal object's (obj's) __proto__ is Object.prototype.
The prototype property of a function object always has a predefined property named constructor whose value is the reference to the function itself (check the above diagram)
wish.prototype, Function.prototype, and Object.prototype are normal objects and not function objects, and hence they have the __proto__ value as Object.prototype
Object.prototype.__proto__ is null—this is defined by the language itself. It marks the end of the prototype chain, which is why Object.prototype is considered the topmost level, and property lookup stops here.
This process—where a property is first searched on the object itself, and if not found, the lookup continues along its [[prototype]] (__proto__ property) chain—is precisely why it’s called Prototypical inheritance.

One final example:

console.log(Function.x)

- Let's become the JS engine again and try to look up the property x

- On the Function object, there is no property named x, so check the __proto__ property of Function and continue the search there. The __proto__ of Function is Function.prototype

- Now let's go to Function.prototype. In Function.prototype also there is no property named x. Check the __proto__ in Function.prototype and go there. The __proto__ of Function.prototype is Object.prototype

- Now check the Object.prototype. There is no property named x in Object.prototype, so check the __proto__ of Object.prototype. It's null. So stop the lookup and return undefined

(Check the above diagram for any confusions.)

Inheritance chain (instance and static):

The previous section could be heavy, but once that is cleared, there is not much left to understand in Prototypical inheritance.

In this section, let's see how to implement inheritance in JavaScript (via [[prototype]])

In the new keyword section, we saw that new keywords set the newly created object's [[prototype]] (__proto__ property) to the constructor function's prototype

Ex:

function RateLimiter(limit) {
  this.limit = limit;
  this.requests = 0;
}

let user1RateLimiter = new RateLimiter(5);
let user2RateLimiter = new RateLimiter(10);

Now user1RateLimiter and user2RateLimiter are two objects from the RateLimiter constructor function

Exercise: Try to run the 4 activities done by the new keyword

In the memory, 2 objects are created, and each object will have its own copy of limit and requests, because the new keyword creates a new object and returns it (implicit return). This can be checked by following

user1RateLimiter.limit++;
user2RateLimiter.limit++;
console.log(user1RateLimiter.limit) // 6
console.log(user2RateLimiter.limit) // 11

Now what if I need to add a method named isRequestAllowed to check whether the current request should be allowed or not? Basically, we need to check whether the current request number is less than the defined limit or not.

For this, we need to define a method, but where should we define that method? The only condition is this method should be available to all the instances created out of the constructor function.
What if we define the method isRequestAllowed in the RateLimiter function object itself? Will this suffice for our requirement?

Check the following:

Clearly this doesn't work, because when we try to access the method isRequestAllowed on the instance user1RateLimiter (run the algorithm we learned in the previous section), we get undefined.

Because we first search the property isRequestAllowed on the user1RateLimiter object, since it's not found, we check the __proto__ which has the value RateLimiter.prototype (the new keyword sets this), and even in RateLimiter.prototype there is no property named isRequestAllowed, propagating the search to RateLimiter.protoytpe.__proto which points to Object.prototype. Since Object.prototype also doesn't have any property named isRequestAllowed, the search propagates to Object.prototype.__proto__ whose value is null, hence leading to undefined.
So defining the method on the function object itself didn't help us. The correct place to put these methods would be RateLimiter.prototype, the reason being all the objects created from the constructor function RateLimter will have the same __proto__ i.e, RateLimiter.prototype, and hence defining the method in RateLimiter.prototype will make sure that each instance created from RateLimiter can access the method.

console.log(user1RateLimiter.__proto__ === user1RateLimiter.__proto__); 
// true, because both point to RateLimiter.prototype because of new keyword
console.log(user1RateLimiter.isRequestAllowed === user2RateLimiter.isRequestAllowed) // true, because it's the same method both objects reach in chain

Now let's extend the same concept to achieve Parent-Child relationship in JavaScript. Consider the following example:

function Notification() {}

Notification.prototype.formatMessage = function (msg) {
  return `[Notification]: ${msg}`;
}

function EmailNotification() {}

EmailNotification.prototype.send = function (msg) {
  return `Email sent with message: ${msg}`;
};

const emailNotification = new EmailNotification();
console.log(emailNotification.send("Hello")); // Email sent with message: Hello
console.log(emailNotification.formatMessage("Hey there!")); // undefined

- It would be clear why the 2nd console.log gives undefined, simply because the formatMessage property was never found in the prototype chain (EmailNotification.prototype)

- But we want the formatMessage method defined on the Notification function prototype to be available on the emailNotification instance

- Meaning we want to establish a relationship between the EmailNotification function and the Notification function, so when a property isn't found on Notification.prototype, the current next searched place is Object.prototype, because Notifcation.prototype.__proto__ is Object.prototype

- Current Relationship:

- To reach the target, we just need to do a minor tweak to EmailNotification.prototype. We want the chain to look like emailNotification -> EmailNotification.prototype -> Notification.prototype -> Object.prototype -> null

- The magic line that will allow us to do this is:

EmailNotification.prototype = Object.create(Notification.prototype)

By default, every object (except function objects) has its __proto__ pointing to Object.prototype. However, if you want to create an object with a custom prototype, Object.create() allows you to do exactly that by explicitly setting the object’s __proto__.

- So Object.create(Notification.prototype) will create a new object whose __proto__ would be equal to Notification.prototype. And this new object's reference is assigned to EmailNotification.prototype

- The only downside is, as discussed in the previous section, the prototype object present in the function will always have a default key named constructor in it. But due to Object.create(Notification.prototype), we created an entirely new object, hence lost the constructor key, so as a good practice, let's add it back

EmailNotification.prototype = Object.create(Notification.prototype)
EmailNotification.prototype.constructor = EmailNotification

- And that's it; the above 2 lines will help us create the parent-child relationship (inheritance) in JavaScript

The inheritance we observed above can be described as instance-based inheritance, since the lookup chain is followed through the instance’s prototype (__proto__).
Now let's understand static inheritance.

Strictly speaking, JavaScript didn’t have an explicit concept of static inheritance before ES6. With the introduction of classes in ES6, the static keyword formalized this idea, enabling inheritance of static methods and properties across classes.

The idea is simple: instance inheritance works by looking up the [[Prototype]] (__proto__) chain starting from the instance created by the constructor function.

In contrast, static inheritance works by following the [[Prototype]] (__proto__) chain on the function itself (function object)—rather than on its instances.
Let's take an example to understand:

function Animal() {}

Animal.identify = function () {
  return "I am an animal";
};

- If observed closely, we aren't defining the identify method in the Animal.prototype object; rather, we are defining this method on the Animal function object itself, and these are what are considered static methods in ES6.

- Now let's define the child class:

function Cat() {}
console.log(Cat.identify); // undefined
console.log(Cat.identify()); // cannot invoke function on undefined

- I hope at this point, we are clear why Cat.idenify returns undefined. Because the property identify was not found in the function Cat [[prototype]] chain (__proto__ chain). Search order: Cat -> Cat.__proto__ = Function.prototype -> Function.prototype.__proto__ = Object.prototype -> null

- Now what we want is property identify to be available to the function Cat, meaning we have to tinker with the __proto__ chain such that, once not found in Cat, the next search should happen in Animal (and not in Function.prototype).
- The magic line that will allow us to achieve this is:

Cat.__proto__ = Animal

console.log(Cat.identify);    // [Function]
conosole.log(Cat.identify()); // I am an animal

- By doing the above, we are manipulating the __proto__ chain of Cat to search next in the Animal function object

- And what we witnessed above is called static inheritance in JavaScript.

ES6 Updates:

Awesome that you have reached until here; what we learned in the previous sections officially completes the prototypical inheritance in JavaScript.

But ES6 released a set of new features that allows us to establish inheritance in an easier way.

New keywords introduced in ES6 regarding prototypical inheritance: class, static, extends, and super.

1. The class keyword:

Strictly speaking, the class keyword is just syntactic sugar for constructor functions.
This was mainly for the developers who came from other ecosystems like Java, C#, etc. But under the hood it's the same constructor function.
Example:

class User {
    constructor(name, age) {
        this.name = name;
        this.age = age;
    }

    wish() {
       console.log(`${this.name} says Hi`);
    }

    static isValidAge(age) {
       return age >= 0 && age <= 120;
    }
} 
const u = new User('Peter', 25);
console.log(u.name);  // Peter
console.log(u.age);   // 25
user.wish();          // Peter says Hi
User.isValidAge(18);  // true

Under the hood, the above class becomes:

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

User.prototype.wish = function() {
    console.log(`${this.name} says Hi`);
}

User.isValidAge = function(age) {
    return age >= 0 && age <= 120;
}

- i) The code written inside a class constructor essentially becomes the body of the underlying constructor function.

- ii) The instance method defined in the class (wish) is added to the User.prototype (so that instances can have access to this method)

- iii) The static method defined in the class (defined via the static keyword) is added directly as a property on the constructor function (User function object).

The new keyword works the same even for classes. The same 4 activities will be performed by the new keyword in the background.

Classes in JavaScript, by default, will run in strict mode. And can be invoked only via the new keyword.

2. The extends keyword:

The extends keyword is used to establish the parent-child relationship between classes.
Example:

class Animal {
  speak() {
    return "generic animal sound";
  }

  static describe() {
    return "Base class for all animals";
  }
}

class Cat extends Animal {
  meow() {
    return "Meow!";
  }

  static identify() {
    return "Cat class";
  }
}

const cat = new Cat();
console.log(cat.meow());       // Meow!
console.log(Cat.identify());   // Cat class
console.log(cat.speak());      // generic animal sound
console.log(cat.describe());   // Base class for all animals

As we can see, the child class instance (cat) can access properties and methods defined in the parent class (Animal). This is made possible by the extends keyword, which establishes the inheritance relationship between them.

But what it does under the hood is what we do manually in the case of constructor functions.

// set instance inheritance
Cat.prototype = Object.create(Animal.prototype)
Cat.prototype.constructor = Cat

// set static inheritance
Object.setPrototypeOf(Cat, Animal)

We don't need to do the above manually; extends does it on behalf of us.

3. The super keyword:

The super keyword allows us to call the parent class constructor function to perform the initialization of the child object.

Yes, you heard it right—calling super() simply initializes the child class instance using the parent’s constructor; it does not create a separate parent class object.
This might sound surprising, especially to the devs coming from a Java background, where invoking super() first creates the parent class object, but that isn't true in the case of JavaScript
Because remember, all the new syntax that came in ES6 is just syntactic sugar for the traditional construction functions. Invoking super() simply means calling the parent constructor function by passing the child's this.
Let's understand it by an example:

class Animal {
  constructor(name) {
    this.name = name;
    console.log("Animal constructor called");
  }
}

class Cat extends Animal {
  constructor(name, color) {
    super(name); // calls parent constructor on the SAME object
    this.color = color;
    console.log("Cat constructor called");
  }
}

const cat = new Cat('Yapapa cat', 'gold');
console.log(cat.name);
console.log(cat.color);

Output:

Animal constructor called
Cat constructor called
Yapapa cat
gold

Under the hood, the above classes convert to the below constructor functions

function Animal(name) {
  this.name = name;
  console.log("Animal constructor called");
}

function Cat(name, color) {
   Animal.call(this, name);     // important: Calling Animal function with Cat's this
   this.color = color;
   console.log("Cat constructor called");
}

// setting both instance and static inheritance between Animal and Cat
Cat.prototype = Object.create(Animal.prototype)
Cat.prototype.constructor = Cat;
Object.setPrototypeOf(Cat, Animal);

const cat = new Cat('Yapapa cat', 'gold');
console.log(cat.name);
console.log(cat.color);

Now we know that because of the new keyword (new Cat('Yapapa cat','gold')), a new object would be created, and this binds to the new object created, and the same object is passed in Animal.call, and hence on the cat instance, the name property is added (by the Animal constructor function).
A natural question that can arise is, why even initialize the properties in the parent class, as the instance is always of the child class, and why not directly perform the initialization of the instance in the child constructor function itself?

The answer is simple: To not violate the DRY principle, the main purpose of creating a parent class/parent constructor function is to keep the common code together

A parent class/constructor function can have many child classes/constructor functions, so instead of initializing all the properties in the child class constructor itself, a better practice is to perform the initialization of common properties in the parent class/constructor function so that we don't have to repeat the initialization logic in each child class/constructor function

Example:

class Vehicle {
  constructor(brand, year) {
    this.brand = brand;
    this.year = year;
  }
}

class Bike extends Vehicle {
  constructor(brand, year, type) {
    super(brand, year); // common initialization
    this.type = type;
  }

}

class Car extends Vehicle {
  constructor(brand, year, doors) {
    super(brand, year); // common initialization
    this.doors = doors;
  }
}

As we could, we extracted out the common initialization logic to the parent class, saving ourselves from repeating, and super in ES6 is a cleaner way to achieve this instead of Car.call(this, brand, year)

This ends the post. I hope this post added value to your JS learning journey. If yes, please do leave a comment/reaction.

Understanding "this" in JS

Lalit Aditya — Tue, 24 Mar 2026 17:18:43 +0000

this keyword in JS can be trickier to understand at first glance. The obvious reason could be the way the this keyword behaves in JavaScript is different when compared to its peer languages like C++, Java, etc

But to be honest, understanding the this keyword in JavaScript is actually easier than it looks.

There are some fixed sets of rules provided by ECMA. So if we understand those rules, the this keyword is done and dusted.

By the end of this post, I assure every reader will gain complete knowledge of the this keyword in JavaScript and will be able to use the this keyword more confidently in their projects.

Now starting, before actually diving into the this keyword and understanding its behavior, we have to know a few prerequisites, and these prerequisites would majorly clear a lot of dust around the this keyword in JS.

Prerequisites:

The this keyword has a valid meaning only inside an execution context.

Now what does that mean?

JS has primarily 2 execution contexts defined in the language. (Actually, there are 4, but for the moment, we will skip the other 2 execution contexts (Eval, Module)). They are

Global Execution Context
Functional Execution Context

So there's the goal. Understanding this in the above two mentioned execution contexts will help us understand 95% of the this behavior in JS

1. this in Global Execution Context:

Standard Rule: this in GEC (Global Execution Context) will always represent the global object

Now what's this global object? The global object is provided by the Host

If you remember, JS, or more specifically, ECMAScript, is just a specification/contract of the language, and the JS engines (V8, SpiderMonkey, etc.) are the actual software that implements this specification.

These engines convert the JS code to machine-level code (binary).

And these JS engines are usually embedded inside the host.
The host can be a browser (Chrome, Safari, etc.), Node.js, Bun, etc

So, based on the host, the global object might differ, and so might the value of the this keyword.

So the value of the this keyword when checked on the browser console vs. on Node REPL would differ.

But the main point is that the this keyword in GEC would always hold the value of the global object

As we can see, this inside a browser gives a window object (as the window object is the global object inside a browser), but the this inside Node REPL gives a different object with different properties.

Note:
One of the very common misconceptions among many developers is that they assume the global object in Node.js is {}

Because when we try to check the value of this in a file and run that file via Node.js, we see {}

But there's a catch: a global object cannot be empty, and this is clearly evident when we tried to see the value of this in Node REPL.

Then why are we seeing an empty object {}?

The answer lies in how Node.js works internally. Any code that you write inside a file run by Node.js, Node.js will never run that file in the true global scope.

Now, why's that? Before ES6, JS developers had only the var keyword to declare variables, and variables declared with the var keyword are stored in the global scope.

So, if 2 files in a project declare the same variable using the var keyword, it would pollute the global scope. Meaning the variable declared with var would override its previous entry.
Ex: Let's say a project has 2 files named f1.js and f2.js.
If f1.js has declared a variable named with hasPermission with the value true and f2.js has also declared a variable with the same name hasPermission with the value false, and assuming f1 runs first and f2 later, the final value of the hasPermission variable would be false, as running the f2.js file has overridden the value of the hasPermission variable.

Now the results of the file f1.js would be catastrophic, as the whole logic of f1.js would be affected by this overriding, as all the variables declared by the var keyword are stored in global scope.

This was a big problem.

Hence, Node.js provided a solution of its own.

Node.js always wraps your file inside a function, and that function would be internally invoked so that every variable defined with the var keyword will live only inside that file, as the function will create a separate execution context, hence saving the global scope from being polluted.

That also means that any code that is in a file when run by Node.js will be wrapped in a function, and the code truly doesn't run in the global scope of Node.js

But still, the question is unanswered. Why does this give an empty object? This will be answered in the upcoming sections of the blog...

2. this in Functional Execution Context:

As we all know, functions in JS create a new execution context; hence, the this keyword will behave differently inside a function.
But how different?
Standard Rule: The value of this inside a function will depend on how the function is invoked.

Now that leads to a question: In how many ways can we invoke a function in JS?
The answer is 4. They are:

Function invocation (the plain function call)
Method invocation (via an object reference)
Explicit Binding (using call/apply/bind methods)
Constructor invocation (using the new keyword)

So depending on which type of invocation is used, this will be populated correspondingly.

Now let's dissect each invocation style.

1. Function invocation:

The function invocation is the most familiar one. And also simple to understand. A function, when invoked directly by its name and a set of paranthesis

Ex:

function wish() {
    console.log('Hey there !')
}

wish()

In the case of a plain function call, this will always default to the global object. But this is true only when the code is running inside non-strict mode.

NOTE:

ES5 introduced a new mode to JS called strict mode. As the name suggests, running the JS code in strict mode will not allow a few things that otherwise run normally in non-strict mode

And one such thing is defaulting to the global object

So if the code is running in strict mode, this will not be defaulted to the global object, and it will be undefined
Standard Rule: In the case of function invocation, the value of this would be the global object if running in non-strict mode and undefined when running in strict mode

function f1() {
    console.log(this) // prints the global object of Node when running in true global scope of Node. For ex: in Node REPL
}

f1()

'use strict';

function f2() {
    console.log(this) // undefined
}

f2()

The output in the 1st case would be the Node.js global object, whereas in the 2nd case, the output would be undefined

2. Method invocation:

This is the case when a function is present inside an object. And to invoke that function, we need the object reference. Ex:

const obj = {
   name: 'Peter',
   wish: function() {
            console.log(this.name, ' says hi');
         }
}

obj.wish();

Standard Rule: In the case of method invocation, this will become the object on which the function is called.
So in our above example, since wish is called on obj, inside wish, this will point to the obj itself, and therefore this.name will have the value Peter

We can also verify this by printing this inside the wish method. It will give the object itself.

const obj = {
   name: 'Peter',
   wish: function() {
            console.log(this) // `this` will point to the obj itself
            console.log(this.name, ' says hi');
         }
}

obj.wish();

Gotcha:
Just think of what the output of the following code snippet would be ?

const obj = {
   name: 'Peter',
   wish: function() {
            console.log(this.name, ' says hi');
         }
}

const wish = obj.wish;
wish()

If you have guessed undefined, good job; you have guessed it right.

Now why's that?

Always remember the golden rule. this inside a function will always get its value based on how it is invoked.

In our above example, it doesn't matter that the wish variable is getting its value from obj.wish, what matters is how the function is invoked at the end of the day. Here it is, a plain invocation (Case 1)

So in the case of plain invocation, we need to check whether the code is running in strict mode or not. Since we aren't using 'use strict;', our program is running in non-strict mode, and this will default to the global object.

Now, based on the host, the global object would differ. Assume the host is Node.js. In the Node.js global object, we do not have any property named name, hence we get undefined.

The same explanation can be continued if the above program is running in a browser. In the browser, the global object is window, and the window object doesn't have any property named name, hence even in the browser, this.name will yield to undefined

If the same code had run in strict mode, it would have led to a runtime error. And I hope you can guess the reason. As in strict mode, this becomes undefined, and accessing .name on undefined would lead to a runtime error

3. Explicit Binding:

This is a special case where we bind the this value to a specific value and then invoke the function with our given this. (This might sound confusing at first glance but will be cleared very soon.)

And to do this binding, JS has given us 3 methods.
They are:

Call
Apply
Bind

These 3 methods are available to every custom function we define and help us to invoke a function with custom this

Ex:

function demo() {
   console.log('This is a demo function');
}
demo.call(null)

Do not focus on the null that is passed, but the point being, we can invoke the call method on demo.

Now let's see in detail about each of these methods.

i) Call:

Syntax:
call(this, arg1, arg2, ...)

function wish(msg) {
   console.log(`${this.name} says ${msg}`)
}

const obj1 = { name: 'Peter' }
const obj2 = { name: 'Tony' }

wish.call(obj1, "hi");
wish.call(obj2, "hey there");

Now, as you can see, we have reused the same function by passing different contexts.

For the first console log, we get Peter says hi
And for the second console log, we get Tony says hey there

The first argument we pass to call is considered as this and same would be used inside the function.

ii) Apply:

"Apply" is the same as "call." Just that the way arguments are passed to functions differs.

Syntax:
apply(this, [arg1, arg2,...])

Ex:

function wish(msg) {
   console.log(`${this.name} says ${msg}`)
}

const obj1 = { name: 'Peter' }
const obj2 = { name: 'Tony' }

wish.apply(obj1, ["hi"]);
wish.apply(obj2, ["hey there"]);

As you can see, the only difference is that the argument list is passed in an array instead of individual values

After the introduction of the spread operator in ES6, all the places where apply is used can be swapped with call using the spread operator
Ex: wish.call(obj1, ...["hi"])

iii) Bind:

Bind is the most interesting of all. In the case of call and apply, the function is invoked immediately with the context we pass.
But in the case of bind, the function isn't invoked immediately; rather, bind returns a new function with the passed context, and whenever this new function is invoked, the original function runs with the bound context.

Syntax:
bind(this, arg1, arg2, ...) => returns a new function

Ex:

const person = {
  name: "John"
};

function greet() {
  console.log(`Hello, ${this.name}`);
}

const boundGreet = greet.bind(person); // returns a new function and the returned function will always have `this` pointed to `person`

boundGreet(); // Hello, John

// At the end function greet runs upon boundGreet(), but `this` is binded to person

NOTE:

Bind permanently binds this context, meaning you cannot override the context later.

Ex:

const person = {
  name: "John"
};

function greet() {
  console.log(`Hello, ${this.name}`);
}

const fn = greet.bind(person);

fn.call({ name: "Mike" }); // fn has `this` permanently binded to person, and cannot be overridden, hence we see the output as Hello John

Bind can be very useful in the case of callback functions so that the callback functions don't lose the this reference.

Ex:

const user = {
  name: "Peter",
  sayHi: function() {
    console.log(`Hi, ${this.name}`);
  }
};

setTimeout(user.sayHi, 1000);

Try to guess the output of the above code snippet. The answer might surprise you at first.
The output of the code is Hi undefined if running in non-strict mode; else, a runtime error if running in strict mode

You might say, Hey, this happens in the case of a plain invocation call, and that's a perfect observation.

Even though sayHi is invoked on the user object (method invocation - case 2), what we have to observe is that it is passed as a callback function

And now setTimeout has full control over this callback function, and once the timer expires (which is 1000 ms in this case), setTimeout will invoke our callback function

setTimeout would roughly look like (not exact code, but generic pseudo code)

function setTimeout(cb, timer) {
   /*
      Register the timer in node process and wait till timer expires
   */

   // once the timer expires,
   cb() // this is the most important thing to observe, now try to guess what this is ? This is the plain function invocation (Case 1)
}

And that's the reason the output we saw in the earlier code snippet produced output as if it was invoked directly (plain invocation)

Now if I ask you to fix this code so that when the callback runs, we should get the output as Hi, Peter

It's simple if we ask what we need?

We need a function that won't execute immediately and also has a permanent this binding. And that's what bind does.

Fixing the above code snippet.

const user = {
  name: "Peter",
  sayHi: function() {
    console.log(`Hi, ${this.name}`);
  }
};

const sayHi = user.sayHi;
const fn = sayHi.bind(user);  // now fn has a permanent this binding to user and sayHi won't execute immediately at this moment of `bind`
setTimeout(fn, 1000); // Hi, Peter

Gotcha:
Remember we left a question unanswered. Why does this give {} as a result in a Node.js file?

As we already discussed, this is because of Node.js behavior; our code isn't running in true global scope, as Node.js wraps our file inside a function and internally calls this function using the call method.

And to this call method, the first argument passed is module.exports. Initially, when a file is run, module.exports is empty ({})

And we also know that the first argument to call is the this we set, and this is the reason why this gives an empty object in a Node.js file.

Under the hood, code is wrapped in a function. And that function is called via call(module.exports,arg1,arg2 etc)

console.log(this)

So a file like this in Node.js becomes

(function (exports, require, module, __filename, __dirname) {
  console.log("Hello");
});

// and the above function is invoked by Node in the following way
/*
wrapperFunction.call(
  module.exports,   // this ({})
  module.exports,   // exports
  require,          // require
  module,           // module
  __filename,       // filename
  __dirname         // dirname
);
*/

4. Constructor invocation:

The final way to invoke a function is to invoke it using the new keyword.

Syntax:
new fn()

The new keyword broadly does 4 things in the background. They are:

Create a brand new object
Make this point to this new object
Set the new object's prototype (proto property) to the function's prototype
Run the constructor function and return this new object (inbuilt return) if no explicit return is mentioned.

Meaning now this is pointed to the object created because of the new keyword

Ex:

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

const u = new User("Peter", 25);
console.log(u.name) // Peter
console.log(u.age)  // 25

Note:

To understand the constructor invocation completely, we also need to have knowledge of objects and prototypical inheritance, but we will skip this in this blog, as this is purely focused on the this keyword

When the instruction const u = new User("Peter", 25) runs, all the above 4 activities mentioned will run, and finally an object will be returned from the user function (internally), and variable u now holds the reference to the object.

Gotcha

What will happen if we call the user function directly without the new keyword?

This will lead to plain function invocation (Case 1), and depending on whether the code is running in strict vs. non-strict mode, the output might differ.

In strict mode, the program will run into a runtime error, as this is undefined

But in non-strict mode, this will default to the global object, and name and age properties will be added to the global object

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

const u = User("Peter", 25)
console.log(u)           // undefined. without new keyword, there is no implicit return, hence default value undefined is returned
console.log(globalThis)  // (globalThis refers to global object of the host(Browser/Node.js etc)) now globalThis will have name, age properties on it as code is running in non-strict mode by default

So these are the 4 cases inside functions where the this value always changed because of how the function was invoked.

Special Cases:

1. Arrow function:

ES6 introduced a new type of function named arrow functions.
The 2 main reasons why arrow functions were introduced were:

To reduce verbose code
To hold this based on the place they were declared

Now in the blog, we will focus on the use case related to the this keyword

Golden rule: Arrow functions always capture this at the time of creation from the nearest enclosing execution context.

In other words, arrow functions do not have their own this

Syntax:
() => {}

Let's understand the above statement in detail. But before that, let's understand the problem that existed in the first place

Now we know that every function in JS has an execution context, which has an impact on the this value

Take the following example:

const user = {
  name: "Peter",
  greet: function() {
    setTimeout(function () {
      console.log(this.name);
    }, 1000);
  }
};

user.greet();

Now we know that when the greet function is invoked, first the timer runs; post timer expiry, the callback function will be invoked as a plain function call from the setTimeout function, which leads this to either take the global object in non-strict mode or undefined in strict mode.

And we know bind is one solution to solve this problem.

But arrow functions also solve this problem, that too effortlessly compared to bind

Rewriting the same example

const user = {
  name: "Peter",
  greet: function() {
    setTimeout(() => {
      console.log(this.name);
    }, 1000);
  }
};

user.greet();

Now remembering the golden rule, arrow functions capture this on the moment of creation from the nearest enclosing execution context

So the nearest enclosing execution context to our arrow function is the greet function (as functions in JS create execution contexts).
So at the time of creation itself (during the setTimeout instruction), the arrow function will capture this from the greet function

Now what would be the value of this in the greet function?
That depends on how the greet function is invoked. It's invoked by user reference (Case 2), so this will point to the user object itself.
And this this value is captured by the arrow function.

So when the arrow function actually runs after the timer expires, it already has this with it (captured at the time of creation), and this.name prints Peter after 1 ms.

Example 2:

const wish = () => {
   console.log('Hi ', this.name)
}

Try to guess the output. (Assume the host is Browser.)

If you guessed the output as Hi, undefined, excellent, you have understood this in arrow functions.

Again, to answer this, let's remember the golden rule: arrow functions capture this at the moment of creation from the nearest enclosing execution context.

To the wish function, the nearest enclosing execution context is the global execution context, and in the GEC, this holds the value of the global object. And since here the host is a browser, the global object is the window object.

And in the window object, we do not have any property named name, hence .name gives undefined.

Exercise:
Try to guess the output of the same program when the host is Node.js (when run in true global scope vs. when run via file)

Answer: In both cases, .name is undefined, but in true global scope, this holds the value of the node's global object
And when run via file, this has the value of an empty object ({}).

2. Combination of invocations in a functional execution context:

Now we know that this inside a function gets a value based on how the function is invoked.

And we also saw that there are broadly 4 ways to invoke a function in JS.

But what happens when a function is invoked using a combination of these four approaches?

Let's take an example:

const user = {
    name: 'Peter',
    wish: function(msg) {
             console.log(`${this.name} says ${msg}`);
          }
}

const obj1 = { name: 'Tony' };
const obj2 = { name: 'Steve' };

user.wish.call(obj1, "hey there"); //combination of case 2 and case 3
const bound = user.wish.bind(obj2); // combo of case 2 and case 3
bound("on your left")

Now what will be the output of this program?

If we observe, the wish function is invoked by a combination of method invocation using object reference (case 2) and explicit binding (case 3).

Now what should be the value of this ? There's a conflict.

To resolve these conflicts, ECMA has given a precedence order.

Precedence order:
Constructor invocation > Explicit binding > Method invocation > Plain invocation

So according to the binding precedence rules, explicit binding (using call, apply, or bind) takes priority over method invocation.

Hence, the output of the above program would be:

Tony says hey there
Steve says on your left

Ex 2:

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

const obj = {
  name: "Bound Object"
};

const BoundPerson = Person.bind(obj);

// Using `new`
const p = new BoundPerson("Actual Person");

console.log(p.name);

Ideally, bind creates a permanent binding, making boundPerson function to point this to obj, but as per the precedence rules, the new operator takes more precedence.

And hence, this will point to the object returned by the new keyword, leading to the output Actual Person

Exercise: Try running the 4 steps that run in the background when the new operator is used

3. Module scope:

Remember at the start of the blog, we learned that JS has 4 execution contexts defined in the language

And we discussed in detail regarding this behavior in Global Execution Context (GEC) and Functional Execution Context (FEC).

The remaining contexts are:

Eval
Module

We’ll skip eval, since its use is widely discouraged in modern JavaScript.

Understanding this in module scope is pretty easy.

Module scope, introduced in ES6, ensures that each JavaScript module has its own isolated scope, separate from other files.

Standard rule: Modules always run in strict mode by deafult.

Meaning we don't have to explicitly mention "use strict";

If we recollect the case-1 of FEC, i.e., the plain invocation, this always had a possibility of 2 values.
Global object in non-strict mode and undefined in strict mode.

But running the same file as a module cuts down the option to default to a global object, as they always run in strict mode

function wish() {
   console.log(`${this.name} says hi`);
}

Now try to guess the output of this program.
We have spent a lot of time understanding this in FEC. By this time, you could easily spot that this is plain invocation (case 1)

In case 1, we always have the scope to get 2 answers: either a global object (if running in non-strict mode) or undefined (if running in strict mode).

Now, since we know that modules by default runs in strict mode, the output is this becomes undefined and access to .name on undefined leads to a runtime error.

NOTE:
In JS, we can create a module by naming the file with the .mjs extension
Alternatively, by setting the type property to "module" in package.json, the entire project is treated as ES modules and runs in strict mode.

DEV Community: Lalit Aditya

Prototypical Inheritance in JavaScript

Table of Contents

The Confusion:

new keyword and its role in prototypical inheritance:

Objects in JS:

Inheritance chain (instance and static):

ES6 Updates:

Understanding "this" in JS

Prerequisites:

1. this in Global Execution Context:

2. this in Functional Execution Context:

NOTE:

NOTE:

Note:

Gotcha

Special Cases: