Saturday, May 28, 2011

Javascript (multiple) inheritance mechanism

During the last weeks, I've been trying to figure out how I could better write melonJS in order to be more OO oriented (at least in a cleaner way) and to benefit from a simple multiple inheritance mechanism.

I won't go through all of them in details (there is enough posts on the web about them), but basically I came out with the following possible (and popular) solutions :

  • Prototypal based inheritance (through some helper functions)

  • Closure Based inheritance (trough some helper functions)

  • Using Prototype.js library

  • Using Base2 library

  • Using Motools library

  • Using John Resig Technique (based on Prototype and Base2)

Initially the fight was for me  "Propotypal inheritance versus the world", as it's lighter, uses less memory and most of all comes in natural javascript flavor. And with this solution being the most "native" one, it's also easier to integrate with other libraries.

However, when using inheritance and multiple inheritance a lot (like I'm trying to do), source code can really become a mess, as this solution is also the most verbose one, and some helpers are definitely needed to avoid some annoying issues (like constructors being called with no parameters when extending an Object).

So I've been looking around, seeing what was going on, trying to figure out which solution was the most reliable, but also the most popular, made some tests, and finally found this page (among others).

While it was clear for me that using library based inheritance would bring the performance down, I was surprised to see the difference of performances when accessing method ! Of course the test seems a bit old, but seeing the technical explanation behind this result, there is no reason for me it would be different today.

So now I have library based solution that should ease my life with code writing (more OO oriented, and much more clean code) but also giving faster method access. Of course memory footprint is higher, and object creation is slower, but actually who cares (when dealing with games, you just basically create your objects when loading your levels).

At the end the question was : which solution to choose ?

And I finally choosed John Resig one, why ?

  • It's anyway based on both prototype.js and base2 (so I can assume it brings the best of both)

  • it's the most compact solution,with only 25 lines of code

  • Very good general feedback, and seems to be working pretty well

  • Seems to give the best compromise in terms of size and perfomances

That's all guys, however I would be very interested to get your feedback about this, this post is the conclusion of my own analysis on the subject, but if you have any other arguments (or better solutions), I would be very glad to read them as well.

See you soon, in the mean time, I got some work to do :)


  1. I think its a good choice.

    God! How many times i faced this same problem!

    Theres no perfect solution... But it works!

  2. Did you look into backbone.js?
    It offers more than just inheritance, it offers MVC

  3. nope... but after a quick look at their website, I definitely should !

  4. Generally Prototypical OO and inheritance do not sit well with each other.

    You can choose to favour object composition over inheritance (something that is always recommended).

    Something like [traitsjs]( should help with object composition.

  5. Thank you for the link, I'll have a look at it :)

  6. I'm working on an GameAPI as well, and this link seemed to help a lot on this issue:

    Now it only takes two lines of code to make an object inherit a parent's fields, and it keeps the rest of the code fairly clean.

    Of course, the catch is that some inner objects "need" to be reinitialized with every new object, such as arrays and updated objects. Otherwise, everyone will share the same data.

  7. Hi,
    Yes I know that link, but this method did not fully satisfied me. I really wanted to have something close as possible from a clean OO implementation, and having to deal with constructor being called with no parameters (when declaring objecs) and variable pre-initialization and stuff really decided me to go with this !

  8. I also have my own script/module called nmix which does the job quite well: