Jeremy Martin jmar777 at
Fri Jun 28 13:28:51 PDT 2013

I would like to humbly submit that for every one time I've wished there was
sugar for single inheritance (which, admittedly, I have), there are
hundreds of instances in which sugar around duck typing would have been
more beneficial.

I realize that's a little bit apples and oranges, but I feel like it's
worth stressing that in most real world applications there is more pain
involved downstream of object creation than in the object creation itself.
 I have quite a few more thoughts on that topic, but as I fear this may
qualify as a derailment, I'll hush up unless there's more interest in going
there. :-)

On Fri, Jun 28, 2013 at 4:14 PM, Eric Elliott <eric at> wrote:

> 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 pick.
> 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>
>  wrote:
> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at

Jeremy Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list