Fluent JavaScript – Three Different Kinds of Prototypal OO

Note: I’ve presented this as a talk a couple of times. You can see the latest version from O’Reilly’s Fluent Conference: JavaScript and Beyond, 2013. The talk is called “Classical Inheritance is Obsolete: How to Think in Prototypal OO”.

In order to claim fluency in JavaScript, it’s important to understand how JavaScript’s native inheritance capabilities work. This is an often neglected area of JavaScript writing and learning, but understanding it can be dramatically empowering.

JavaScript is one of the most expressive programming languages ever created. In particular, its combination of delegate prototypes, runtime object extension, and closures allow you to express three distinct types of prototypes in JavaScript. Let’s take a closer look at each of these.

Delegation / Differential Inheritance

A delegate prototype is an object that serves as a base for another object. When you inherit from a delegate prototype, the new object gets a reference to the prototype. When you try to access a property on the new object, it checks the object’s own properties first. If it doesn’t find it there, it checks the prototype, and so on up the chain until it gets back to Object.prototype.

Method delegation is a fantastic way to preserve memory resources, because you only need one copy of each method to be shared by all instances. It’s also a great way to add capabilities at runtime to all objects which share a particular prototype.

There are a couple of ways to set up that relationship in JavaScript. The one you’re likely to see in a lot of books goes something like this:

function Greeter(name) { = name || 'John Doe';

Greeter.prototype.hello = function hello() {
  return 'Hello, my name is ' +;

var george = new Greeter('George');

See JavaScript Constructor Functions vs Factory Functions and Stop Using Constructor Functions in JavaScript for my thoughts on why you should ignore this technique. I present it here only because it’s likely to be a familiar point of reference.

I prefer this:

var proto = {
  hello: function hello() {
    return 'Hello, my name is ' +;

var george = Object.create(proto); = 'George';

The one major drawback to delegation is that it’s not very good at storing state. In particular, if you try to store state as objects or arrays, mutating any member of the object or array will mutate the member for every instance that shares the prototype. In order to preserve instance safety, you need to make a copy of the state for each object.

Cloning / Concatenative Inheritance / Mixins

Prototype cloning is the process of copying the properties from one object to another, without retaining a reference between the two objects. Cloning a great way to store default state for objects. This process is commonly achieved by methods like Underscore’s .extend(), or jQuery’s .extend():

var proto = {
  hello: function hello() {
    return 'Hello, my name is ' +;

var george = _.extend({}, proto, {name: 'George'});

It’s common to see this style used for mixins. For example, Backbone users can make any object an event emitter by extending from Backbone.Events:

var foo = _.extend({
  attrs: {},
  set: function (name, value) {
    this.attrs[name] = value;
    this.trigger('change', {
      name: name,
      value: value
  get: function (name, value) {
    return this.attrs[name];
}, Backbone.Events);

Closure Prototypes / Functional Inheritance

I’m cheating on the name for this one. It’s not really functional, and it’s not an object prototype. It’s a function prototype. Think of it as an alternative to a constructor / init function. It can be copied (inherited) from one factory to another, and combined with other functions like it to completely replace the need for super() (which is a code smell, and should be avoided).

Closure prototypes are functions that can be run against a target object in order to extend it. The primary advantage of this style is that it allows for encapsulation. In other words, you can enforce private state. Douglas Crockford called this style “functional inheritance” in his book, “JavaScript: The Good Parts”. It looks something like this (Foo, like above, with private attributes):

var model = function () {
  var attrs = {};

  this.set = function (name, value) {
    attrs[name] = value;
    this.trigger('change', {
      name: name,
      value: value

  this.get = function (name, value) {
    return attrs[name];

  _.extend(this, Backbone.Events);
};, 'Top secret');

george.on('change', function (e) { console.log(e); });

george.set('name', 'Sam'); // Object {name: "name", value: "Sam"}

This is all well and good, but there’s an awful lot of jumping through hoops if you want to combine the techniques — so I wrote a little library to jump through the hoops for you. It’s called Stampit.


Create objects from reusable, composable behaviors.


  • Create functions (called factories) which stamp out new objects. All of the new objects inherit all of the prescribed behavior.
  • Compose factories together to create new factories.
  • Inherit methods and default state.
  • Supports composable private state and privileged methods.
  • State is cloned for each instance, so it won’t be accidentally shared.
  • For the curious – it’s great for learning about prototypal OO. It mixes three major types of prototypes:
    1. differential inheritance, aka delegation (for methods),
    2. cloning, aka concatenation/exemplar prototypes (for state),
    3. functional / closure prototypes (for privacy / encapsulation)
  • What’s the Point?

    Prototypal OO is great, and JavaScript’s capabilities give us some really powerful tools to explore it, but it could be easier to use.

    Basic questions like “how do I inherit privileged methods and private data?” and “what are some good alternatives to inheritance hierarchies?” are stumpers for many JavaScript users.

    Let’s answer both of these questions at the same time. First, we’ll use a closure to create data privacy:

    var a = stampit().enclose(function () {
      var a = 'a';
      this.getA = function () {
        return a;

    It uses function scope to encapsulate private data. Note that the getter must be defined inside the function in order to access the closure variables.

    Let’s see if that worked:

    a(); // Object -- so far so good.
    a().getA(); // "a"

    Yes. Got it. In both of these instances, we actually created a brand new object, and then immediately threw it away, because we didn’t assign it to anything. Don’t worry about that.

    Here’s another:

    var b = stampit().enclose(function () {
      var a = 'b';
      this.getB = function () {
        return a;

    Those `a`’s are not a typo. The point is to demonstrate that `a` and `b`’s private variables won’t clash.

    But here’s the real treat:

    var c = stampit.compose(a, b);
    var foo = c(); // we won't throw this one away...
    foo.getA(); // "a"
    foo.getB(); // "b"

    WAT? Yeah. You just inherited privileged methods and private data from two sources at the same time.

    But that’s boring. Let’s see what else is on tap:

    // Some more privileged methods, with some private data.
    // Use stampit.extend() to make this feel declarative:
    var availability = stampit().enclose(function () {
      var isOpen = false; // private
      return stampit.extend(this, {
        open: function open() {
          isOpen = true;
          return this;
        close: function close() {
          isOpen = false;
          return this;
        isOpen: function isOpenMethod() {
          return isOpen;
    // Here's a mixin with public methods, and some state:
    var membership = stampit({
        add: function (member) {
          this.members[] = member;
          return this;
        getMember: function (name) {
          return this.members[name];
        members: {}
    // Let's set some defaults: 
    var defaults = stampit().state({
            name: 'The Saloon',
            specials: 'Whisky, Gin, Tequila'
    // Classical inheritance has nothing on this. No parent/child coupling. No deep inheritance hierarchies.
    // Just good, clean code reusability.
    var bar = stampit.compose(defaults, availability, membership);
    // Note that you can override state on instantiation:
    var myBar = bar({name: 'Moe's'});
    // Silly, but proves that everything is as it should be.
    myBar.add({name: 'Homer' }).open().getMember('Homer'); 

    41 thoughts on “Fluent JavaScript – Three Different Kinds of Prototypal OO

      • Eric Elliott says:

        Axel – I agree that mixins work best when added to prototypes. You can extend a new prototype like this:

        `Object.create(_.extend({}, aProto, someMethods));

        “One advantage of constructors is that many engines optimize for them.”

        There really isn’t a big performance difference. In fact, there isn’t much different going on functionally, at all, except that the constructor has to jump through **extra hoops** to interpret new and set up this. If you follow best practices and do the instanceof check in your constructors, that’s another step (and potentially another method call), as well. In other words, while they can optimize away, they’re really just trying to figure out how to speed up what is inherently a slower process than just running a normal function. Throw the common block of = that; into the mix (vs something like return Object.create(someProto);), and you have a recipe for slow.

        See JavaScript Constructor Functions vs Factory Functions.

        As for that prototypes-as-classes link — what they’re saying is that the new class keyword in JavaScript is going to work a lot more like the methods I prescribed in this article. One major difference — I do not advocate building deep inheritance chains. Keep it as flat as you can.

        Thanks for your feedback!

        • Eric Elliott says:

          Looks pretty bad if all you look at is prototype assignment, right? But that finding gets flipped on its head if you look at instance property assignment (the bit that actually varies between objects). See this factory vs constructor perf.

          It’s pretty easy to tell the story you want to tell, just by being selective about what you test. And since Object.create() is a native method, when we see more use in the wild, it will get the same type of optimization attention that constructors got — and since the operation is inherently less complicated, it could potentially be optimized even better (it doesn’t have to mess with new or set up instanceof, or branch for different return behaviors in the constructor function).

        • There is no Object.create anywhere in this jsPerf you posted. Returning an object literal is of course faster than constructor usage, which is still significantly faster than Object.create.

          As you say, after more usage in the wild the optimization could improve and it could “potentially” be optimized even better but in today’s real-world JavaScript, constructors are much faster than Object.create.

        • Eric Elliott says:

          All fair points, but I’d be careful not to put too much weight on this aspect of it, because:

          1) That particular difference is very likely to get optimized away in the engines — possibly soon, and
          2) If you really want the best possible performance, you should be using factories that return object literals, instead of constructor functions or Object.create() — but this is unlikely to become a bottleneck in a typical JavaScript application. Far more likely culprits will be your choice of algorithms, data structures, I/O, DOM manipulations, or page reflows.

          It’s good to be aware of performance implications, but it’s a bit silly to point at perf results and conclude that the technique is never useful, simply because there’s another technique that happens to have a better performance profile. Sometimes a slight perf tradeoff is worth it, because of the gains in clarity or flexibility in your code.

        • There’s actually a **HUGE** performance difference between cloning objects using constructors, and cloning objects using Object.create. However, the performance of all other operations on the object after you’ve created it have pretty much the same performance. You can see a test case for this here: (That test case is almost two years old now, and I really should have separated the operations since it’s a pain to compare in this state. But you can use the `Table` view).

          Anyways, from a practical standpoint, Object.create is likely to perform okay in all situations even with the unfair overt-optimisation of creation through constructors. For example, my library for property-based testing in JavaScript (a “port” of ScalaCheck/QuickCheck) is prototypes all the way down, using Object.create exclusively, and even though every possible operation clones the previous object for immutability, it still has an acceptable performance (also note that this makes the delegation chain *huge*). The architecture is also much different than most other JS applications because you’re probably not creating a thousand of objects every millisecond ­— unless you’re writing a game engine.

          So, Object.create’s performance is not great, but it is acceptable today for most stuff. Ditching it for constructors just because they’re faster now isn’t really a good argument.

        • Eric Elliott says:

          If you’re making a game engine and generating rapid-fire bullets or something at the tens-of-thousands-per-second rate, constructors still don’t give you best case performance. Object literals do. Unless each object has a lot of big methods attached to it, in which case I’d say your object architecture needs re-thinking. =)

          So if you’re optimizing for speed, you still don’t want to use constructors.

    1. Am I missing something, or the only way to actually have a “inheritance” chain is by using a constructor or Object.create which is basically a empty constructor ??

    2. Max Shishkin says:

      Just few days ago I was looking for some cleaner and more flexible solution to plain classic-like inheritance via prototypes, and now I’ve found one! Really like it, will try to use in the upcoming project. Thanks!

    3. Ed says:

      I really like this approach and Stampit seems very convenient and elegant.

      The one thing that’s always bugged me about javascript inheritance is that there’s no built-in “super”-like keyword, even though other purely prototypal languages like self and Io have this feature. It makes it really difficult to method overrides with more than 1 level of inheritance.

      • Eric Elliott says:

        I don’t suggest that you use more than one level of inheritance, and I find that, while I do use method overrides and prototypal inheritance together, the only thing I do that’s like super is the stacking of functional inheritance that happens when you compose multiple stamps which implement closures (the .enclose() feature).

        I find that trying to use something like super tends to get error prone and hard-to-debug quickly.

        • Eric Elliott says:

          I have no intention of implementing super. Martin Fowler thinks super is a code smell, and I agree. I have a strong distaste for the tight coupling it requires between the child and the parent. As soon as you give the child instance a handle to the thing its inheriting from, you’ve broken encapsulation, and reintroduced the same brittle architecture we were trying to get away from in the first place when we switched to prototypal OO.

          Instead of super, there are a million things you can do: facade, dependency injection, “abstract interface”, etc… The last one presents something interesting (and the one Martin Fowler recommends). You can implement base features and then provide hooks for the “concrete” instances. I put quotes around those of course because every object in JavaScript is a concrete instance, but in this case, the “abstract” version defines an exemplar interface that the concrete object can implement using hooks — the hooks are the bits you’re supposed to override, whereas the interface bits should not be overridden.

          For example, if you were building a media player, you could define .play(), .pause(), and .volume() methods on the interface. Lets say all of these operations require some business logic that must be implemented regardless of the tech — for instance, the .play() method needs to check to see if the user is authorized to play the media.

          These methods can be set up to call hooks: .techPlay(), .techPause(), and .techVolume(). Now you create an html5Player and a flashPlayer. They return objects that define the .tech* methods. Using stampit, you could inherit from both the base media player and a tech player to create your working player instances.

          I would argue sternly that defining yet another level of inheritance which needs to override those same methods again is probably a bad idea. With each level of method override you add, you increase the complexity and opportunity for trouble exponentially.

          Besides, it’s more likely that what you really need to do is emit an event from .play() that any object can listen for in order to implement additional behaviors or manage cross-cutting concerns.

    4. Greg Baker says:

      Great find! …nice read.

      I recently did something similar in search of a better way – need was secondary at the time. My solution was far more convoluted, less flexible and incomplete (yet fully tested.) So this is timely for me. I will go back and see where I went astray; but I may simply scrap it for your small lib instead. Thanks for the article and coce.


      • Eric Elliott says:

        This is my second go at a library like this. It’s easy to second guess other people’s design choices, but much harder to crank out a solid design yourself. My first attempt had some good things going for it, but ultimately fell short of the mark, and it was more complicated than it needed to be. I think this one hit the sweet spot. At least for me. Let me know what you think if you decide to use it. =)

    5. Pingback: You’re Optimizing the Wrong Things | Eric Elliott - JavaScript Architect (A JavaScript Blog)

    6. Thiago Figueiredo says:

      Great article.

      Also, this bit in one of your comments should be repeated over and over again:
      “It’s good to be aware of performance implications, but it’s a bit silly to point at perf results and conclude that the technique is never useful, simply because there’s another technique that happens to have a better performance profile. Sometimes a slight perf tradeoff is worth it, because of the gains in clarity or flexibility in your code.”

      To the new and the old guys. To ourselves too.

    7. Mike Lippert says:

      Stampit sounds interesting, and you make some reasonable arguments for writing JS code in this style (I’m new to JS and trying to figure out how best to structure my project and currently trying to get my head around Closure), but it needs real documentation rather than just some simple examples.

      The readme says “you can chain methods…” and provides an example that doesn’t tell me what methods is or why I would want to chain them.

      I don’t have any familiarity w/ _.extend(), $.extend(), and ES6 Object.mixIn(), so referencing them as the sole documentation for methods and state isn’t very helpful.

      I’m looking forward to understanding more though.

    8. Pingback: Stampit 0.3 Released « Eric Elliott – JavaScript Architect (A JavaScript Blog)

    9. Christian says:

      Hi Eric,

      in medias res: you seem to know your stuff 😉 And so does Andrea Giammarchi.
      I am really curious what you think about his way of achieving inheritance in Javascript:

      Though his coding style is nowhere nearly as easy to decipher (at least for me), what caught my interest in his post was (among additional things) the part where he writes: 

      Yeah, one of the coolest things about being able to inherit from null is the fact not even Object.prototype is inherited so we can create real empty objects without worrying about surrounding environment, 3rd parts obtrusive libraries, and the boring and slow obj.hasOwnProperty(key) check.

      That’s correct, objects that inherit from null are not affected by the Object.prototype. Really, we cannot even print them without defining a toString method!

      From a purist’s point of view, I feel that having such a truly blank state for objects and constructs to be build upon sounds very appealing (and even secure, maybe?)

      Thanks in advance

      • Eric Elliott says:

        That implementation is a bit convoluted and serves little purpose. The existing MDN Object.create polyfill works great if all you want is the first Object.create argument, and if you want to be able to loop over an object without worrying about hasOwnProperty, you could just use a utility like mout/object/forOwn — IMO, a much less brittle way of accomplishing the same goal. You’ll note that he’s jumping through a lot of hoops and assuming browser environments for something that should be generically useful in any JavaScript environment. What about Node?

        In future versions of JavaScript, this will all be a moot point, because we’ll have a native own property loop.

    10. Michael Bennett says:

      I haven’t played with the code yet, but this looks really solid. I’m especially attracted to composing factories from other factories. I wish I’d been able to read this three years ago before I learned a lot of this the hard way.

      Actually who am I kidding, I wouldn’t have understood, I went to school in the late nineties when everyone was shoving Java, and classical OOP down people’s throats. I had to learn JS the hard way, and I’m still learning.

      Thanks for this library, and the talks. I hope this helps more people embrace the power of the lambda.

    11. Benjamin Gruenbaum says:

      You know someone is not serious when they call classical inheritance ‘obsolete’. In the JavaScript world, classical inheritance and more accurately structural (rather than behavioral) subtyping is still a useful design pattern that has several use cases. 

      Pretending that it’s not is lying to yourself. The strength in JS is that it lets you do prototypical OOP _in addition_ to classical OOP.

      • Eric Elliott says:

        I’ve heard this a lot from people with classical OO backgrounds (much like mine), but I’ve never seen any actual evidence to back it up. Please spell out some of those use cases, and why they are better than composition or factory functions.

      • Eric Elliott says:

        BTW, I’m quite serious. I don’t believe that there are any use cases where classical inheritance is a better fit than composition, delegation, or functional code reuse (or a combination of the three).

    12. Matt Wistrand says:

      By setting methods directly in the function prototype…
      var model = function() {
          this.set = function() {};

      do you not lose the memory benefits of a delegation prototype, since those methods need to be recreated as separate instances each time is executed? At which point should we care about this?

      • Eric Elliott says:

        Hi Matt,

        You do lose those memory benefits. If memory is a consideration, you should be setting them on the delegate prototype, rather than the instance. If you need the benefits of the closure, you’re explicitly deciding that you need memory allocation at the instance level (usually for encapsulation of instance state). That’s when you’d use the functional variety instead of the delegate prototype.

    13. This is a beautiful concept. One note though: do you really think the mixin and closure prototypes are different enough to merit their own categories? I could see the model being simplified to just two types of “inheritance”: delegate which involves properties of the prototype, and mixin which involves properties of the object itself. In terms of API, you could have two methods .delegate() and .mixin() that could each take as argument either an object (in which case it would do straight copying) or a function which would be used to create closures. This could simplify your implementation as well, as you could have a single private method behind the scenes handling both cases.

        • Eric Elliott says:

          Tarek – Impressive work. I disagree with your assumption that it’s better with two methods, instead of three, but that doesn’t make your implementation any less interesting.

          If you’re interested in pursuing it as a viable alternative to Stampit, take this gist and drop it into the stampit test folder to get an idea of the level of feature parity you have achieved… I took the liberty of adding some aliases so the Stampit tests would work:

    14. james says:

      I’ve  been reading, in the middle of, various books.. js ninja, functional js, allonge etc.. reading blogs etc.. and i am having difficulty wrapping my head around the level of eloquence and difficulty you bring. How does one reach this level of technique? Write and create js etc…? My work does not bring the need for this level BUT i want to reach it.

      Any advice? Tutorials? Books?

    Leave a Reply

    Fill in your details below or click an icon to log in: Logo

    You are commenting using your account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s