Eric Elliott eric at
Fri Jun 28 13:14:57 PDT 2013

I've already invested significant time in trying to shed more light on this
topic. In my book, in that video, in blog posts, and now here. Take your

The cliff notes for the lazy (with sketchnotes!)

What I want to say has been said many times before: class inheritance
causes problems that do not even need to exist in JavaScript. The Gang of
Four considered this so important, that they made it one of two principles
which are a central theme in the "Design Patterns Book"... but even the
first principle is related, so I'll start there:

"Program to an interface, not an implementation",

If you need a reference to the parent class in the implementation of the
child class (the part that is expressed in the code of the language user),
that is a violation of that principle. That is why "super" is considered to
be a code smell.

and "Favor composition over class inheritance."

The reason for that is that deep inheritance hierarchies are too tightly
coupled (child to parent), and too dependent on parent implementation (see
above). These problems cause code arthritis as projects mature and you
begin to inherit from sub-classes. Eventually that leads inevitably to
brittleness, and the  famed gorilla banana problem.

"The problem with object-oriented languages is they’ve got all this
implicit environment that they carry around with them. You wanted a banana
but what you got was a gorilla holding the banana and the entire jungle." -
Joe Armstrong, "Coders at Work"

Debugging such structures can be challenging. Changing them can force
large, time consuming refactors, and in some cases, complete project
rewrites. I've seen this happen in the real world again-and-again. Mostly
in C++ and Java.

When I came to JavaScript in the late 90's, it seemed like there was some
relief from that. I just didn't see things like that happening very much...
despite being involved in JavaScript-heavy serious applications for almost
all of my career.... Until Backbone caught on and made .extend() the
defacto way to reuse code in a very popular library. Then suddenly
everybody started subclassing in JavaScript like it was a brand new idea.

Then I started seeing those problems I thought we'd left behind resurface
in real-world applications for companies producing apps with millions of
users. Serious problems with major code bases in the wild... because people
were running with a pattern that was never a good idea.

It is a particularly bad idea in JavaScript primarily because using it is
actually harder than using the better alternatives that already exist
natively (notably a single prototype (not a userland chain), and dynamic
object extension, which makes mixin implementations trivial). My argument
is that it should *stay harder to implement*.

Not only do we not need class, what we have is much easier, much more
flexible, and dramatically less problematic. Some great alternatives to
classes include modules (particularly those that export functions), factory
functions, object literals, Object.create(), and simple dynamic object
extension. You can combine all these and create some neat sugar that
doesn't involve single-ancestor inheritance, tight coupling between parent
and child, and encouraging users to think in a broken paradigm.

More reading (if you can find the time):

Sketchnotes -
Slideshow source -

Blog post -

Different author, similar message - (3 parts)

- Eric Elliott

On Fri, Jun 28, 2013 at 11:40 AM, Tab Atkins Jr. <jackalmage at>

> On Fri, Jun 28, 2013 at 11:31 AM, Eric Elliott <eric at> wrote:
> > I'm not here to discuss the mechanics of what class does. I'm just
> saying we
> > shouldn't do it in the spec. There are better alternatives that pose less
> > threat to the JavaScript ecosystem.
> >
> > A handful of libraries and JavaScript authors twisting prototypes to make
> > them less useful is one thing. Getting a blessing from on-high for
> people to
> > teach that it's "how to do inheritance in JavaScript" in teaching
> materials
> > is quite another thing.
> It is how you do (single) inheritance in JS.  In your OP, you say "I
> think we should wait for some patterns to gain a foothold in the
> wild".  Single inheritance via prototype chains is an immensely
> popular pattern for this kind of thing.  You do qualify your statement
> by saying we should wait for *good* patterns, but single inheritance
> is perfectly good for some things, and adequate for quite a bit else.
> There are certainly better patterns, but none of them have gotten wide
> traction yet.  We definitely want to pursue something like mixins in
> the future, but in ES6 we purposely went for a "maximally minimal"
> class syntax, adding as little as possible while still achieving the
> readability and usability gains of having a dedicated syntax.
> For example, when we come up with a good mixin pattern, adding it to
> the class syntax is as easy as doing "class Foo mixin Bar, Baz, Qux
> {...}".  No clash with "extends"; it just slots in cleanly.
> > My arguments (and a few suggested alternatives) are in the video.
> >
> > If you're going to blow off what I have to say about it because you don't
> > have time to watch a video, I guess the conversation is over. =)
> In our private conversation, I just asked for a text version, as it's
> several times faster to read text than listen to a talk.  It would
> likely take you roughly as much time to write out the points you want
> us to take from the video as I, individually, would save by being able
> to read them instead of having to watch the video.  When multiplied
> over the whole mailing list (or at least the people interested enough
> in this thread to care), the balance of time is clearly on the side of
> "just spend the time writing out what you want to say".
> ~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list