Understanding the prototype property in a Javascript object

The prototypal nature of Javascript is both a common cause of confusion and a well documented topic. I’m not going to look at the basic theory here because it’s been done many times; if you are interested in the basics there is a very good document on MDN. Instead, I would like to outline a few simple experiments which illustrate the properties of a prototype chain and why you might want to take advantage of them.

For the basis of this post, I’m going to use the Constructor pattern and look at the following simple example:

If you were to look at the football object in your browser’s debugger you would see that it has a property called prototype which is a reference to its prototype chain. The chain would go:

Sphere → Object → null

Now, that code can be rewritten using the prototype property of Sphere, like so:

As you can see, the result is the same. But, if one were to compare the two version of the football object they would see a difference. In the first incarnation “pi” and the “volume” function are both own properties of football; in the second version those two properties are no longer part of football but instead are properties of its prototype, Sphere.

You can prove that by changing the value of “pi” in the prototype:

So, without changing football at all, its reference to “pi” has updated. As “pi” was not an own property the prototype chain was consulted and value found in Sphere. That has a very important implication: for any instances of Sphere there is only one object which is the prototype. That is, if we created a second Sphere, called tennisBall, it would not just have the same properties in its prototype as football, it would have a reference to exactly the same object as its prototype. So if “pi” is updated in the prototype it is updated for every instance of Sphere.

That can be a useful property in of itself but it has huge implications for application performance. Suppose we create a large number of Spheres. In the original example (without using the prototype property) there would be a property “pi” and a function “volume” created once for each instance of Sphere; when those properties are part of the prototype they will only be created once. So for a million Spheres there would either be 3 million properties (a radius, pi and volume for each) or 1 million and 2 properties (a radius for each and a pi and volume in the prototype). That makes a huge difference to performance:

Using properties of the prototype:

Using own properties:

On my laptop, the version with the properties stored in the prototype ran in 0.563 seconds, verses 1.349 without. That’s more than three times the speed!

So, it’s not just about coding style: the prototype property is very important, particularly when your code creates many instances, and needs to be understood. If a property is likely to be unique to the instance then it should be ab own property, otherwise it’s often worth moving it into the prototype.

Leave a Reply

Your email address will not be published. Required fields are marked *