Discussion

1. Niek

   Nice article! But most of the time I’m using the “init/constructor” function on the Bar object to run additional initialization code (in addition to the Foo initialization code), and that functionality is not available in the “Object -> Object” example. Code re-use through polymorphism is difficult in JavaScript without using any tricks or hard-linking the Foo and Bar objects. I hope ES6 will solve this.
• Kyle Simpson

  Yes, very important point you’ve made.

  If you need multi-level initialization, you have the unfortunate choice that you either use the same name init() at each level, and then you deal with the frustrations of hard-coded polymorphic references, OR you can give each init task a unique name, which is often a better idea anyway, and if you do that, then this.fn() style calls will work safely (and relatively) through the [[Prototype]] delegation chain as you’d want.

  For instance, say you had one set of initialization at Foo level which set the identity, and another set of initialization at the Bar level which customized some output preferences:

  Foo.setupIdentity = function(who) { this.me = who; };
  //..
  Bar.setupOutputPrefs = function(prefs) { /* .. */ };
  Bar.init = function(who, prefs) {
     this.setupIdentity(who);
     this.setupOutputPrefs(prefs);
  };
  //..
  var bar1 = Object.create(Bar);
  bar1.init( "b1", { /*..*/ } );
  

  It’s better software practice to use specific task names rather than try to “overload” a generic name like “init”, so this sort of design is not only more maintainable, it happens to fit very well with the style of code I’ve presented here.

  Hopefully that helps! :)
• Gregor Elke

  @Kyle you don’t have to hard-code the polymorphic reference:

  var foo = {init : function(){console.log('foo init'); this.foo = true}}
  var bar = Object.create(foo)
  bar.init= function(){
          Object.getPrototypeOf(Object.getPrototypeOf(this)).init.call(this)
          console.log('bar init')
          this.bar = true
  }
  var b = Object.create(bar)
  b.init() // foo init // bar init
  console.log(b.foo, b.bar) // true true
  

  it looks a bit ugly with the double calling getPrototypeOf, but it works, and is generic from this point. one gotcha is, that oyu have to check for the existence of the init method, at the end of the chain there is no such method anymore.
• Kyle Simpson

  @Gregor-

  Unfortunately, that’s a very dangerous approach. It only works when you have 2 levels of the chain. If you ever had a third level, you’ll have to change all such occurrences with an extra getPrototypeOf call, and a fourth level later will mean yet another call in all those places. It’s a refactoring footgun of the worst variety.
• rhysbrettbowen

  I Should really check my code first:

  var super = function(obj, fnName) {
  	var current = Object.getPrototypeOf(obj);
  	while ((current = Object.getPrototypeOf(current))) {
  		if (typeof current[fnName] == 'function') {
  			return current[fnName].apply(obj, [].slice.call(arguments, 2));
  		}
  	}
  }
  
• rhysbrettbowen

  realised it wouldn’t work for the second super call, so here is one that should work based off of goog.base:

  var super = function(fn) {
  	var caller = super.caller;
  	var found;
  	for (var child = object.getPrototypeOf(this); child && child[fn] typeof == 'function'; child = Object.getPrototypeOf(child)) {
  		if (!found)
  			found = true;
  		else if (child[fn] != caller)
  			return child[fn].apply(this, [].slice.call(arguments, 1));
  	}
  }
  
• Kyle Simpson

  @rhys I think your final code snippet makes my point for me. It is POSSIBLE to traverse the prototype chain each time you want to make a super call… that’s what my currentThis polyfill did. But it’s terribly ugly and inefficient, so much so that I’d argue it’s impractical to use such techniques. It’s exactly this kind of ugliness that I was referring to in several places when I condemned polymorphism (the relative kind) in JS.

  On a side note, you could have done:

  Bar.init = function() {
  Object.getPrototypeOf(Bar.prototype).init.call(this);
  };
  

  Technically, THAT is a relative sort of super call… where at least it isn’t hard coding Bar to Foo. However, there are gotchas with this approach too, and there is unquestionably a lot of ugliness to that sort of coding. That style of code is highly likely to be done wrongly, and even if it’s right, it’s harder to understand/maintain later. All of those are points I made throughout the article series on why that style of code is something I think that makes JS [[Prototype]] harder to use/understand. It’s not just a lack of syntactic sugar, it’s that fundamentally we don’t have a currentThis or super, and our workarounds for that are, IMO, uglier than polymorphism is worth.

  I posted another comment here on this article where I suggested another way to deal with multiple-levels of initialization without relying on polymorphism. That’s the style of code that I think is WAY better to write. Just my opinion, though.
• Zach

  Is this mad? https://jsbin.com/kopogu/2/edit?js,console
2. Corbin Supak

   Thanks for the article. Could you recommend more material to study that approaches the language in the manner you do? My eventual project work will be for multi-player (local, 100 or fewer users) game and info-viz application with heavy use of MySQL data. Thanks again.
• Kyle Simpson

  At the risk of sounding too glib, I have a blog I plan to write more on soon, and I’m also planning to launch a kickstarter in the next few days for a new book series I want to write on JS, so I think you should read more of my stuff! ;-) (keep an eye out here for announcements for my kickstarter)

  But, seriously, Angus Croll and I seem to have a lot of mindset about JS in common, and he writes some great stuff on his blog. Hope maybe that helps for now.
• Kyle Simpson

  FYI, I have indeed launched my Kickstarter for the book series “You Don’t Know JS”. Check it out and help spread the word!
• Kyle Simpson

  Oops, sorry, wrong link. Here’s the correct link.
3. ariutta

   Thanks for this series. In the previous post, you said that composition “has plenty of goodness to it,” but you also call composition a “distraction.” When would you recommend using composition in a JavaScript project?
• Kyle Simpson

  What I meant is that composition is one of many distractions that lead you into believing that behavior delegation is actually some bizarre sort of inheritance. When used on its own, composition is fine, but it shouldn’t be used in the context of creating “classes” as a workaround for the weirdnesses of JS’s system.

  As an example, you could have a Router object that you expose as a .router public property on your UIManager object, as opposed to wiring UIManager to delegate to Router via [[Prototype]]. This would be composition, as a property on an object that is itself some other object.

  What would sorta introduce confusion/distraction is if you used composition to hide the fact delegation wasn’t working the way you wanted classes to work.

  You can of course mix both patterns in the same project, but it’s HOW you use composition that matters, because it can be used for good or used as a tool of confusion by the inheritance crowd.

  The goal is to keep these concepts separate (and use them independently to their full power) instead of using one to confuse/conflate the other. Behavior delegation has been so confused and overlooked because of all the other OO jazz that I really wanted to set all that aside so we could examine BD all by itself.

  Does that clarify what I mean?
4. ariutta

   Yes, that makes sense. Thanks again!
5. Sebastian

   Great Post. I’m with you Constructor Functions only make things confusing.

   I always heard that Constructor Functions are a lot more performant than Object.create, so I made a test: http://jsperf.com/object-create-vs-constructor-function.

   At least in Chrome (V8) that seems to be the case. So this is a little gotcha of going the Object.prototype way.
• rhysbrettbowen

  I believe this has to do with the javascript engine. If you use a constructor function and don’t add or remove any of the instance properties after instantiation then the engine can cache the type of an object which speeds things up.
• Josh Farneman

  Yes, this is a difference between javascript engines. I’ve made a revision of your jsperf test using the two full code samples above at http://jsperf.com/object-create-vs-constructor-function/3. You can see that new is about 38% faster in Webkit, while Object.create is about 43% faster in Firefox. In Opera new is about a 4% faster. So you can see how the differences in the optimizations made by different js engines have a significant impact on the performance of the two styles.
6. Sebastian

   I meant Object.create way.
7. db

   Nice article. I think this is a really interesting approach to defining “class” structures in js. However, I’m going to challenge your claim that this method works ‘without any of the confusion/distraction of “constructor functions”, new, .prototype, etc.’ All of those aspects are still there, just hidden within Object.create(). The polyfill implementation from mozilla’s site gives a glimpse into what’s going on inside Object.create():

   Object.create = function(o) {
       function F() {}
       F.prototype = o;
       return new F();
   };
   

   The technical aspect of creating constructor functions, setting up the prototype, and calling ‘new’ is still happening. This is evidenced by the fact that b1.constructor === Object. So at minimum the Object() function is getting called.

   The diagrams in this article depict purely conceptual differences. There’s no technical difference between using “new” or Object.create(). All the same constructor functions and prototype structures are getting created. It’s just happening behind the scenes with Object.create().

   That said, the coding approach you’ve outlined here is easy to understand and certainly clarifies delegation vs. inheritance concept. The only downside I see is that it breaks the use of ‘instanceof’, but I think that is acceptable given the option of using isPrototypeOf().

   On a side note, I’d recommend using a convention where the ‘init’ method returns ‘this’ to allow object creation to be chained:

   var Foo = {
       init: function(who) {
           this.me = who;
           return this;
       }
   };
   
   // ...
   
   var b1 = Object.create(Bar).init("b1"); // little cleaner
   

   Thanks for the article. It certainly got me thinking about things in a new way.
• rhysbrettbowen

  unfortunately isPrototypeOf only checks the prototype back one level, you may want to know if it’s got a certain prototype further back in the chain, though we can always fix that with something like:

  var hasPrototypeOf = function(proto) {
  	for (var current = this; current; current = Object.getPrototypeOf(current)) {
  		if (proto.isPrototypeOf(current)) {
  			return true;
  		}
  	}
  	return false;
  }
  
  var isType = hasPrototypeOf.call(myObject, typeToTestFor);
  
• Kyle Simpson

  @rhys – I think you’re mistaken. isPrototypeOf() will check all the way up the chain, given the right context. So, in my coding example, Foo.isPrototypeOf(b1) is true, even though there’s two levels b1 -> Bar -> Foo.
• Kyle Simpson

  @db – I think there’s a number of differences that make Object.create() different from constructor-style coding:

  1. the fact that all objects are created (or at least appear to be) by the Object() constructor doesn’t mean that constructors are happening throughout the rest of the code base. That’s basically a hidden implementation detail. AIUI, the JS engine is free to construct those objects however it wants, as long as the behavior stays the same, which is that the Object.prototype has a constructor that points to Object(). In short, I’m not entirely certain that those objects ARE actually created by Object(), but even if they are, that where the constructors stop in my example, as opposed to being strewn throughout.

  2. Again, implementation-wise, I don’t think the Object.create() actually needs to create an empty constructor function just to throw it away after creating our new object and linking it. Yes, that’s how the polyfill looks, but I don’t think necessarily that’s how it happens under the covers. Certainly, ONE BIG difference is that IF the constructor exists at all, it is hidden away and does not end up polluting the namespace.

  3. Another difference with Object.create() is that you can actually create an object that has absolutely no [[Prototype]], by calling Object.create(null), which is NOT something you can do with normal constructor-style coding.

  I stand by my claim: “without any of the confusion/distraction of ‘constructor functions’, new, .prototype, etc.” because none of those things are EVIDENT in the simplified code, which means that our code style is cleaner and easier to reason about, which was the whole point of the series. This isn’t a blog post about implementation details inside the JS engine, it’s about how we clean up our code style to reveal the true power of JS’s [[Prototype]] instead of shrouding it in the other confusions.
8. Robin

   Great posts … ANd thanks for all comments’ conttributors too

   Series was great for a newbie to OOP aspect of JS like me… I learnt a lot on OOP aspect of JS
9. Neovov

   What about static members?

   Nice articles!
10. Wil Moore III

    Excellent post and series Kyle. I enjoyed comparing the outlined solution to what I do today. FWIW, I tend to go back and forth between “.constructor” and Object-based (i.e. Object.create).

    Definitely a trade-off and I still don’t see one being better than the other in “All” situations, unless the only goal is a simpler mental model. Object.create wins easily here.

    That being said, there is one thing I’ve been unable to work out with `Object.create` and `Object.getPrototypeOf` (to be fair, I haven’t been sufficiently motivated to solve this since I’ll happy lean on constructors to get the job done). Unless I am missing something simple, don’t we have a minor x-browser issue?

    The `Foo` object has no `.constructor` property and `__proto__` is not available everywhere. This makes it difficult to properly polyfill `Object.getPrototypeOf `.

    Have you been able to find a clean workaround?
• Kyle Simpson

  Great question, Wil. I actually have looked into that, and was going to highlight it here but the article series was already pretty long and in-depth.

  I’ve played around with this notion of an Object.make(..) helper that does what Object.create(..) does, but also makes sure that every object it “makes” has, at minimum, a __proto__ and (delegated) access to isPrototypeOf().”>https://gist.github.com/getify/5226305″ rel=”nofollow”>an Object.make(..) helper that does what Object.create(..) does, but also makes sure that every object it “makes” has, at minimum, a __proto__ and (delegated) access to isPrototypeOf().

  an Object.make(..) helper that does what Object.create(..) does, but also makes sure that every object it “makes” has, at minimum, a __proto__ and (delegated) access to isPrototypeOf().”>

  This means that not only can old browsers still benefit from this approach, and use a simple polyfill for Object.getPrototypeOf() (which relies on __proto__), but even in new browsers, if you do Object.create(null), you end up getting a truly empty object that is NOT linked to Object.prototype, so it won’t have __proto__ or isPrototypeOf() either, which is a bummer. Object.make() normalizes that by adding back those, as bare minimum additions. Hope maybe that helps.
• Kyle Simpson

  Doh. Sorry for the busted link. Here’s the correct link to Object.make().”>https://gist.github.com/getify/5226305″ rel=”nofollow”>correct link to Object.make().

  correct link to Object.make().”>
• Kyle Simpson

  Argh. https://gist.github.com/getify/5226305
11. Jorge Antunes

    I thoroughly enjoyed your 3-part article. What made it so much easier to understand was the visual representation that you gave, in addition to the well-explained subject with minimal code. I hope your upcoming books will be in a similar style.

    The only thing I have a hard time wrapping my head around is how to best handle this n that. Should I still use the that = this; pattern to access it within a function or is there a cleaner way I’m overlooking?
• Kyle Simpson

  Jorge: there are 4 ways that this gets set inside a function execution.

  Was the function called with new? If so, the use the object new created.
  Was the function called with call or apply specifying an explicit this? If so, use it!
  Was the function called via a containing/owning object (context)? If so, use it!
  DEFAULT: global object

  When you learn those and all the different ways they play out (like using hard-binding with Function#bind(), etc) then you much more rarely need to mix `this` with closures, which is what the var self = this; kind of coding is all about. Every once in awhile you do it, but once you learn closures and `this` separately and deeply, the awkward mixes of them are reduced.

  BTW, one of the books in my You Don’t Know JS book series kickstarter is going to be all about this exact topic!
• Jorge Antunes

  Awesome, thanks for the response. I thought you’d be nice enough to leave an answer.
  I’ve already chipped in for the books, just wanted to know about “this” straight-away so I can continue coding and researching on my own terms.
  Take your time with the books, make them good.
  I can’t wait :)

  PS: thanks for your answer too Wil
12. Wil Moore III

    Hi Jorge,

    Regarding `that = this`…You will likely get a different answer from just about anyone you ask; however, what I tend to come up with a name that makes sense given the context.

    Instead of:

    var that = this;

    If this is an audio player, I’ll do:

    var player = this;
13. Webbower

    This is a great writeup. However, I’m running into some of the problems the other commenters have inquired about. I’m trying to figure out how to make this version of JS coding work for my purposes (as well as many other people’s, I’m sure), but it seems like there are things missing that classical OOP style handles more gracefully. This seems like a great idea in theory, but stumbles in a lot places for practical use. It would be awesome if you wrote a follow-up to all this that showed some practical implementations using this. There’s a lot of frameworks out there shimming class-based practices onto JS like the MV* and Widget libraries and many of them heavily utilize polymorphism to initialize up the chain and extend/override parent properties.

    I guess I’m putting out the challenge to put your money where your mouth is on this one. I’m definitely not one of the JS masters so my understanding is probably more limited than yours, but I’ve got a solid understanding of writing JS and I was trying to figure out how to build the foundations of a UI/Widget framework for my company using this method you excellently outlined, but I’m running into limitations (also taking into consideration my aforementioned skill level with JS).

    Thanks again for the great write-up!
• Kyle Simpson

  I’d love to know more specifics on issues you’re having. But I agree we need to see real code, not just academic ideas. When/if I get something more concrete to show you, I will post back here. Also, watch my blog. :)
14. Kars Meyboom

    How about Strictly-Objects as opposed to Object-Based? The latter has the same “fuzzy” feel to it as Object-Oriented does; neither really explains what it means.
• Kyle Simpson

  I now use “OLOO” (objects-linked-to-other-object) to contrast with “OO”.
15. Rotor

    Finally I can understand what all this .prototype stuff is all about! It makes so much more sense if you stick to patters for which the language was originally designed for.
16. Andy

    This was a good writeup. Do you have any real life projects that are using the object only model? Or do you know of any popular libraries that are doing this?
17. Yassine

    I finally understood ! I read dozens of articles and none was clearly saying things. Thank you so much!
18. Dumitru "Mitică" UNGUREANU

    Hi.

    Looking at the Inspector in browser’s Web Developer Tools, things look virtually the same.

    With no subclass (no Bar), the init function for prototype replaces the constructor function for classical.

    With subclass (with Bar), we have an additional constructor function for every subclass, for “classical”.

    I know I can trust the Inspector. Your diagrams…?
• Kyle Simpson

  That’s not correct. In the above final objects-only code snippets, init() exists **only** on Foo object, and will not be duplicated on Bar or on any of the b1, b2,… or even b997. Delegation will “share” that method across all those objects, which means there’s only one init() that they all use.

  Moreover, the objects-only style of code produces the exact same objects and the exact same [[Prototype]] relationships as function-constructor style code, but with vastly less code complexity.
19. Alvaro

    Best javascript article ever!! I was looking exactly for this :) I’ve been reading dozens of blogs and books about how to write “good” object-oriented javascript code. But I was shocked by the creepy solutions proposed to do that. Thank you very much for enlighten us!!
20. Michael Prescott

    I’m still trying to digest this. It seems it will lead to more succinct code for myself, and understandable. I’ve been inspecting objects and properties, and comparing to my current style’s results. It makes sense, but I’m lost on a few points. I really need to have multi-level initialization. In much of our work, we do:

    SubBase1.prototype.init = function() {
        Base1.prototype.init.call(this);
        // Additional SubBase1 initialization...
    };
    
    So, I'm trying to replicate that in some fashion using what I'm learning here.  Here's what I have:
    
    var Base2 = {
        prop1: 'prop1val',
    
        init: function() {
            console.log('Base2.init()');
            this.prop1 = this.prop1 + '-updated';
            this.prop2 = 'prop2val';
        }
    }
    
    var SubBase2 = Object.create(Base2);
    
    var sb2 = Object.create(SubBase2);
    
    // Attempt to call 'super' function
    sb2.init = function() {
        console.log('SubBase2.init()');
        Base2.init();
    };
    
    sb2.init();
    
    sb2.newprop = 'newprop';
    console.log('   sb2.prop1=' + sb2.prop1);
    console.log('   sb2.prop2=' + sb2.prop2);
    
    inspect(sb2, Base2, SubBase2);
    

    Initially newprop is the only property of sb2 not inherited through the prototype chain. Updating prop1 via Base2.init() keeps the property as an inherited one; however, updating or setting any property from the instance will make the property a direct one of sb2 instead of an inherited one. For example, sb2.prop1 = 'newvalue' or sb2.prop2 = 'prop2val-set-by-instance'

    So, considering all. What is wrong with just calling Base2.init() from a redefined sb2.init()?
• Michael Prescott

  I think that just the usage of naming class style naming conventions in my example leads to confusion. As noted (many times) these aren’t classes, just objects. So, in the above, ‘prop2’ isn’t even defined until Base2’s init is called. Anyhow, I’m still questioning what problems would arise from calling Base2.init() from sb2.init(). Also, since updating the value of any inherited property from the instance is essentially eliminating the inherited property and creating a direct one, if we wanted to maintain the inherited properties we’d need to access all via setter functions.

  Oh, here’s my inspect():

  var inspect = function (obj, BaseClazzObj, SubBaseClazzObj) {
      console.log('---- Prototype Inspection ---\n');
  
      console.log('Is prototype of BaseClass: ' + BaseClazzObj.isPrototypeOf(obj));
      console.log('Is prototype of SubBaseClass: ' + SubBaseClazzObj.isPrototypeOf(obj));
      console.log('Instance is prototype of BaseClass: ' + (Object.getPrototypeOf(obj) === BaseClazzObj));
      console.log('Instance is prototype of SubBaseClass: ' + (Object.getPrototypeOf(obj) === SubBaseClazzObj));
      console.log('BaseClass is prototype of SubBaseClass: '  + (Object.getPrototypeOf(SubBaseClazzObj) === BaseClazzObj));
  
      console.log('\n---- Property Inspection ---');
      //The following example shows how to iterate over the properties of an object
      // without executing on inherit properties.
  
      var name;
      for (name in obj) {
          if (obj.hasOwnProperty(name)) {
              console.log('   hasOwnProperty():' + name + ' = ' + obj[name]);
          } else {
              console.log('  !hasOwnProperty():'+ name + ' = ' + obj[name]);
          }
      }
  };
  
• Michael Prescott

  Nevermind. I think I understand now. When overriding/resetting sb2.init() and then calling Base2.init() from within it, I’m simply setting Base2’s properties after I’ve gotten properties from it. This makes it so that sb2 no longer has it’s own ‘prop1’, and ‘prop1’ is only accessible from the sb2 instance due to the prototype chain (?)
21. Damon Black

    What are the performance implications of this pattern? From what I understand, an important reason for use of .prototype is to attach methods that are only created once, on an object’s constructor’s prototype, rather than being recreated with every call of the new keyword. Is this true of your object->object method?

    In other words when i do

    var b1 = Object.create(Bar);
    b1.init("b1");
    

    am I calling a new object method (therefore adding to memory usage) or calling up the delegation chain and using Bar.init (afaik in the ‘classical’ method i would call a pre-existing method on the prototype, not creating a brand new method).
• Kyle Simpson

  With the objects-only style of code, you are still creating exactly the same objects with exactly the same [[Prototype]] linkages as you do with function-constructor style. So, the performance characteristics will basically be identical, because everything’s still the same.

  The difference with objects-only style code is that it’s vastly simpler to write and reason about. But the end result is functionally pretty much identical.
22. Ellie

    I am very happy to read this. This is the type of info that needs to be given and not the accidental misinformation that’s at the other blogs. Appreciate your sharing this greatest doc.
23. Liudas

    Hi,
    nice article. But… correct me if I’m wrong – this concept fails on object properties that are objects themselves.

    var A = {
    	listeners: {},
    	count: 0,
    	add: function (name){
    		this.listeners[name] = "value";
    	},
    	plus: function() {
    		this.count++;
    	}
    };
    
    
    function info(value) {
    	console.log('---- ' + value + ' ----');
    	console.log('a.listeners: ', a.listeners);
    	console.log('b.listeners: ', b.listeners);
    	console.log('a.count: ', a.count);
    	console.log('b.count: ', b.count)
    	console.log('------------------');
    }
    
    var a = Object.create(A);
    var b = Object.create(A);
    
    info('BEFORE');
    
    a.add("aaa");
    a.plus();
    
    info('AFTER');
    
• Kyle Simpson

  Yes, but that would fail identically in the function-constructor style of code too. What you’re observing (correctly) is that storing data on a delegated-to object is BY-DESIGN going to be shared data with everyone else. This is exactly the same truth as if you had put a property on the “parent class (object)” that you instantiated/inherited from in function-constructor style.
• Guido

  Why is the data shared? I totally don’t get it. :D
• bortch

  how about that ugly way?

  var A = {
      listeners: {},
      count: 0,
      that:this,
  	add: function (name){
          var old = Object.create(this.listeners);
          this.listeners = {};
          old[name] = name;
  		this.listeners = old;
  	},
  	plus: function() {
  		this.count++;
  	}
  };
  

  displays:

  ---- BEFORE ---- (index):39
  a.listeners:  Object {} 
  b.listeners:  Object {}
  a.count:  0
  b.count:  0
  ------------------
  ---- AFTER ----
  a.listeners:  Object {c: "c", b: "b", a: "a"} 
  b.listeners:  Object {f: "f", e: "e", d: "d"} 
  a.count:  1 
  b.count:  0 
  ------------------ 
  

  -> http://jsfiddle.net/t9SZt/
24. aeoril

    This is a watershed article for me on how to effectively do JavaScript “OB” programming – thanks, and good work! I will be doing a lot of re-factoring!

    Why not return this from init( ... ) so you can do the following?

    var b1 = Object.create(Bar).init('b1');
    
• Kyle Simpson

  That’s a perfectly fine suggestion and I do that sometimes. I just didn’t want to muddy the article more with introducing even more different paradigms. :)
• Tim

  I do something like:-

  new: function(who) {
      var bar= Object.create(this);
      bar.init(who);
      return bar;
      }
  [...]
  var b1= Foo.new("b1");
  
• Supersharp

  I use to do the same with create instead:

  var b1 = Foo.create("b1")
  
25. aeoril

    Here is a possible way to use your very good ideas:
26. aeoril

    Here is a possible way to use your very good ideas:

    var Vector2D = {
        create: function () {
            return Object.create(Vector2DProto);
        },
        add: function (vec1, vec2) {
            return vec1.clone().add(vec2);
        }
    }
     
    var Vector2DProto = {
        init: function (x, y) {
            this.x = x;
            this.y = y;
     
            return this;
        },
        clone: function () {
            return Vector2D.create().init(this.x, this.y);
        },
        add: function (vec) {
            this.x += vec.x;
            this.y += vec.y;
     
            return this;
        }
    }
     
    var vec1 = Vector2D.create().init(3, 4),
        vec2 = Vector2D.create().init(6, 8),
        vec3 = Vector2D.add(vec1, vec2);
     
    vec1.add(vec2);
     
    console.log(vec1, vec3)
    
27. aeoril

    arrgghhh! I cannot get the code to display right!
28. aeoril

    Here is a follow on post of mine inspired by this one:

    http://aeoril.github.io/javascript/2014/03/28/object-based-vs-constructor-based-coding-in-javascript.html
29. Liudas

    Another bad thing for this kind of JavaScript coding style is standard minify/uglify – it does not minifies properties on object, thus script footprint will be larger.

    Interesting approach but keeping in mind inheritance and footprint I don’t see any reason to use this kind of approach on anything rather than small “singleton like” object. I think “the prototype base” coding is much better approach.
30. Jeremias Menichelli

    This is great and very clear, my concerns are memory and performance though. I’m pretty sure that new is way faster than Object.create but leaves a mess in memory for object relations. Do you have any thoughts about performance and memory Kyle?
• Kyle Simpson

  @Jeremias —

  Yes, in fact I do have detailed thoughts on it, and have put that all into a separate blog post here: http://blog.getify.com/sanity-check-object-creation-performance/

  TLDR: the speed/memory performance you’re concerned about is almost certainly a non-issue.
31. James

    Hey Kyle — I find your series awesome, but I do have an issue with the verbose’ness of many of your explanations in relation to new vs. Object.create vs. OLOO etc…

    Is it possible you can just list our the benefits, detriments in layman terms of using classical class implmentation, delegation, OLOO etc.. I find myself having to read thru 10pages of your book(s) to find a point but it gets lost in so much sugar/extraneous explanations that one can lose the point before too long … I’d much prefer you list the positives, negatives and then expand on them rather than having the reader try to identify the points you are making and where. Just my 2 cents. For example, you mention how mimicking class creating creates issues.. exactly what are these issues? When in a chain of object creations does this issue come out?
32. danilodeveloper

    Hi @Kyle!
    What do you think about it: https://gist.github.com/danilodeveloper/c62303ff50bd6059dbfd

    IMHO it’s more readable because uses Foo.create or Bar.create instead of Object.create(Foo), and ensures that the init function will called.
33. SpagBol

    Thank you so much Kyle, this is exactly what I was after.

    Question – It’s been 2 years since you posted this pattern, do you still use OLOO or have you found an alternative?
• Kyle Simpson

  Yes, I still OLOO. I still use it in the ratio as before, compared to the module pattern, which is about 95% modules, 5% classless-objects-with-delegation (aka OLOO).
34. Rick

    An absolute excellent post. Excellent study and presentation. Excellent writing.

    Whatever approach a JS coder takes to satisfy a requirement, there is nothing better than understanding the environment in which a choice is made.

    Not only have you given your reader the ability to make an informed choice on their approach but you also gave them the ability to create. Nothing incarcerates the mind more than using a lib as a flashlight to find a door to execute a solution.

    Only the bold and the beautiful take the time to liberate.
35. Omer Moarn

    Great article and series!
    Really enjoyed reading this, taught me a lot.
    I have a question,
    How would you override a method and then call the parent’s method?
    For example, for init in b1?
    something like this (but one that’s working :))?

    b1.init = function(){
    //own init code
    //now, call parent's
    Object.getPrototypeOf(this).init.call(this, "b1");
    };
    

    How would you do it in an elegant, cross browser way?
36. Rick

    Omer,

    This is where your thinking has to be re-engineered. Kyle has written a great series of books. You might want to start here (https://github.com/getify/You-Dont-Know-JS/blob/master/this%20&%20object%20prototypes/ch6.md), which builds on what he puts forth in this article.
• Omer Moarn

  Hi Rick,
  Thank you for the link, I will look through that.
  I know, it’s definitely a “re-engineering” as you stated and I like it a lot.

  Do you have a TL;DR for me about calling the base method from the child method after overriding it?

  Thanks again.
• Omer Moran

  Bar is still the base object for b1 and b2.

  Even in this architecture there *might* be a need to call the base method.
  Since we don’t want it to be tightly coupled, I wonder how can we call the base method without knowing the name of that base.
• Rick

  The TL;DR is showing in your replies. There is no ‘base’, there is only OLOO (Objects Linked to Other Objects). And when done correctly, there is no need to ‘call’ a base class, since any request will merely flow down stream (or ‘up the prototype chain’) and be found.
• Omer Moran

  I think that I was mis understood.
  I am talking about cases where you want to implement an own object’s method *and after that* call the base method.
  Look at the example that I wrote.
  Implement b1’s init, do something in there AND THEN call the original b1 init.
37. Omer Moarn

    Hi,
    How can you resolve the storing state issue?
    For example, when you are adding an array to Foo and you want it to be unique for every object?
    Here’s a jsbin example:
    http://jsbin.com/jafaru/1/edit
• Omer Moarn

  OK, I get it.
  You need to point the array to another memory reference by creating a new array.
  Is there a more elegant way to resolve it as I did?
  http://jsbin.com/coqipi/1/edit
38. Baptiste Pesquet

    Hi Kyle,

    First of all thanks for this enlightening series of articles. Like many other, I’m still trying to digest it.

    I am a CS teacher with a strong C++/Java background. I’m currently writing a introductory course to programming with JavaScript. The OOP chapter is of course the most challenging. I have written an example program a bit more complicated than yours to illustrate the main OO concepts, using the new ES2015 syntax (see gist). As you may have guessed, i find it clean and expressive.

    However, I have chosen to stick with ES5 for now and must translate this example to the “old” syntax. I came across your work and tried to use the OLOO style, but I still cannot mimic the sheer elegance and expressiveness of class-based OO. OK, I may be biaised :)

    Maybe this example will be of interest to other would-be JS coders out there.
    Thanks in advance for your advice.

    https://gist.github.com/bpesquet/6dac5adeb5f31fdc1951#file-rpg_es2015-js
• Baptiste Pesquet

  After a bit of research, I came along with another solution (hopefully) written in the OLOO style :

  https://gist.github.com/bpesquet/c7b9ac3745b38ccc2827#file-rpg_oloo-js

  Anyway, these articles just made be a little bit better at JavaScript, so thanks again !
• Wil Moore III

  Hey Baptiste,

  Glad to see that you wrote up a couple POCs. That makes the discussion a bit more informed. I took your example a little further using just Object.create, Object.assign, and functions (no constructors, no new, no class):

  https://github.com/wilmoore/polykata/tree/master/oloo-game-player-poc/js#oloo-game-player-poc
39. Jokro

    Thx very much for your great exposure. It turned me over to OO.2

    I wonder if the following two declarations are equivalent from the Object Only perspective:

    Foo={myname:name,....}

    function Foo(){}
    Foo.myname=name
    

    …
    I prefer declaration 2 for its visual appearance in case of complex situations, but wonder if it implicitly invokes the constructor.
40. Vincent

    Hello. Coding (for real) in JS since about one year, I’ve started to read articles about Eric Elliot thoughts, etc, and ended up there. Beyond this great article and the time you spent writing it, I have a question.

    When you do

    Bar.speak = function() {
        alert("Hello, " + this.identify() + ".");
    };
    var b1 = Object.create(Bar);
    

    a major difference by doing

    Bar.prototype.speak = function() {
        alert("Hello, " + this.identify() + ".");
    };
    

    is that in the first case, the speak method is duplicated each time you will instantiate a new object with Object.create, while it won’t in the second case.
    Am I right ?
• Kyle Simpson

  Am I right ?

  Nope. :)

  function Foo(){}
  Foo.prototype.hello = function(){};
  
  var Bar = {
     hello: function(){};
  };
  
  var a = new Foo();
  a.hello();
  
  var b = Object.create(Bar);
  b.hello();
  

  In this case, both a and b have the same shape, which is that neither of them got a copy of the hello() method. Both of them delegate up the [[Prototype]] chain. It’s just that a delegates to a weirdly named Foo.prototype object, while b delegates to a more sensibly named Bar object.

  Otherwise, same shape, same usage characteristics and performance, etc.
41. Tilwin

    I’m almost mindfucked seeing your second diagram – that the prototype of the Function() constructor having call, apply & bind methods is a function represented by a circle, rather than a square which represents an object like the rest of prototype objects in the diagram.

    Please tell me that this is a mistake, or was done intentionally to trick people into thinking that its literally impossible to mentally digest the constructor based way of coding.
• Kyle Simpson

  @Tilwin-

  Nope, no mistake, and not a conspiracy either. The reason that Empty is a function rather than just another plain object is that all functions gain their ability to be functions (and not just objects) from that first function.

  Regular functions in your program delegate to Empty to get access to apply(..), etc, but they also “delegate” to (actually inherit from)Empty for their ability to be executable.
• Tilwin

  @Kyle Thanks, What you’re saying makes more sense now. (I did some further reading after adding the comment. Even though I haven’t got my head around those stuff completely, this diagram is very helpful :)
42. anil

    Hello sir,
    Wonderful post.I saw the style of inheriting behaviors with delegation.You wrote it without the use of constructor function and “new” keyword.But you used Object.create which itself internally used “new” keyword.
    If Object.create is using “new”.Is it that bad to use “new” keyword compared to what is explained in the article.
43. Liva

    Hi @Kyle,

    Thanks a lot for you explaination, i tried this code-style and it works like a charm.

    But, i noticed somethings strange during my tests. Look at this code snippet :

    Toto = {
        charac: { foo: 1, bar: 1 }
    };
    
    TotoBrother = Object.create(Toto);
    TotoBrother.charac.foo = 4; // take a look at this !
    TotoBrother.charac = { foo: 2, bar: 2 };
    TotoBrother.charac.foo = 6;
    
    var toto = Object.create(Toto);
    var totoBrother = Object.create(TotoBrother);
    console.log(toto); // output end 1, for 4 !!!
    console.log(totoBrother); // output end 2, for 6
    

    It seems that TotoBrother.charac.foo points to its delegated Object (Toto.charac.foo), affecting its value !!! But if you overload with an object, things goes right after…

    Tested on Chrome 49.0 and FireFox 44.0.2

    Thanks a lot again !
• Liva

  For comprehension, a make mistake in my comments, should be :

      console.log(toto); // output bar 2, foo 4 !!!
      console.log(totoBrother); // output bar 2, foo 6
  

  Thanks a lot
44. D

    Great article, but what about encapsulation? Your approach does not allow the use of private variables.
45. Ben

    This is a good article, very well written – but Object.create feels sloppy to me in the examples provided – maybe its because I’m used to far more strictly typed “Class” languages?

    Why define Foo then do Foo.Prototype.Whatever=function afterwards? Why not just define this.Whatever=function within Foo and have Bar reference that? You’re defining new Foo() anyway so what benefit does Prototyping have in that scenario? Foo and Bar are now very clearly linked without the use of prototyping.

    Using prototype as a method to inherit another object (‘Model’ Inherits ‘BaseModel’ for example) purely to read that object’s properties is nice and quick – but if I try to write to foo.bar the prototype foo.prototype.bar disappears and and I end up with the property bar in object foo – headaches ensue.

    So it feels sloppy to me. I’m sure it has its benefits but for the type of coding I do I think I’ll just stick with the new keyword.

    Could you or someone else provide more practical examples? IE: In C# I’d have class Person inheriting class AddressDetails and be able to read and write Address information.
• Kyle Simpson

  @Ben

  > Why not just define this.Whatever=function within Foo and have Bar reference that?

  IIUC, this represents a fundamental misunderstanding of the mechanism. Consider these two, which it sounds like you’re claiming are functionally identical:

  function Foo() {} Foo.prototype.hello = function() { console.log(“hello”); };

  var f = new Foo();
46. Tomer

    This series is great and very useful, and I certainly have to chew it a lot more to grasp all that data. Yet, like “D” asked above and was not answered: My main issue with this is encapsulation. It’s possible only method-by-method, and there’s nothing the object as a whole can use as private data. I avoid using “new” for sometime already, but the main method I use so I can encapsulate is sort of a factory that returns an Object with methods, while the private parts (methods and members) are within the factory function.
    How can it be simulated with the object-linked methodology?
47. Sam

    there’s something strange in the first diagram, speak()‘s .__proto__ is pointing to identify() which implies that identify.prototype is the reference link of speak() but of course that’s not the case, beside the log shows that the only relation between speak() and identify() is that one (speak()) is a direct property of Bar.prototype and the other is a method of its __proto__ link, so why speak() is pointing to identify? what did I miss?
• Kyle Simpson

  You’re misreading the diagram. It’s not saying that `speak()`’s __proto__ is pointing anywhere.

  `speak()` is property on an object (the square around it), which is commonly known as `Bar.prototype`, and thus it is `Bar.prototype.__proto__` that is pointing to another object (square) called `Foo.prototype`, which itself happens to hold another property: `speak()`.
48. Benjamin Forster

    I know this article is quite old now but it looks like the instanceof in your last example does not work.

    Calling instanceof with an object returns this error:

    TypeError: Right-hand side of 'instanceof' is not callable

    Has the behaviour of instanceof changed since this article was originally written?