Julien Richard-Foy’s blog

Functional inheritance vs prototypal inheritance

Dear Lazy Web, should I use “functional inheritance” or prototypal inheritance?

I need a way to reuse and extend pieces of code so I looked at different ways to perform inheritance in JavaScript. Finally, I have to choose between “functional inheritance” (as it is called by Douglas Crockford) and prototypal inheritance, but both have pros and cons, so that’s not an easy choice...

Functional inheritance

The functional inheritance pattern is well explained in Douglas Crockford’s book: JavaScript, The Good Parts. Basically, an object constructor function creates an empty object and adds it some methods before returning it. Inheritance is achieved in this object constructor function by getting the object through another object constructor function instead of creating an empty one. Example:

Is see the following advantages of the use of the functional inheritance pattern:

Prototypal inheritance

In prototypal inheritance, objects are created using the new keyword, and inheritance is achieved by linking the object’s prototype to another object’s prototype. Example:

I see the following advantages of the use of the prototypal inheritance pattern:

At this point of the review, the choice is really hard because on one hand we have a simple and trap-free system (functional inheritance) which just does well the job, and on the other hand a faster and more flexible system (prototypal inheritance) but less straightforward to use (inheriting from a class needs to both call the ancestor constructor and the inherits function) and, even worse, more error prone since you cannot pass an object’s method as a callback parameter unless you explicitly take care of wrapping it in a function ensuring that its execution will be performed using the right context (try it here!).


I’d love to use the prototypal inheritance pattern if it was possible to simplify its usage and to automatically take care of binding methods on the right context object.

CoffeeScript solves both problems. It allows to use prototypal inheritance in an easy way, avoiding redundancies of vanilla JavaScript and (almost automatically) taking care of the context object of instances methods (as long as you use the right symbol, “=>”, to define them).

However, I wrote a little benchmark measuring object creation time and method call performance when using either functional inheritance, prototypal inheritance or prototypal inheritance with all methods bound to the instance object (a la CoffeeScript). Here is the interpretation of the results:

These results throw doubt on my mind: prototypal inheritance performance is significantly less interesting when methods are bound to their instances. Actually overall performance may be better with functional inheritance since in a real application lifecycle, few objects are created after the initialization phase but using them involves a lot of methods calls. Furthermore, as a framework designer I don’t want to force users to use CoffeeScript to be able to easily write their classes, and I couldn’t find a way as easy as with CoffeeScript to use prototypal inheritance in vanilla JavaScript.

That’s why I think I’ll use functional inheritance. Unless someone sees a better solution?

blog comments powered by Disqus