Classical inheritance is obsolete

Axel Rauschmayer axel at
Sat Jun 29 19:07:11 PDT 2013

On Jun 29, 2013, at 20:12 , Eric Elliott <eric at> wrote:
> If I were advertising, there are better places to do it, and better ways. I feel like adding class to JS would be detrimental to the language and the users of the language, and I feel that the previous discussions on the topic did not make a strong enough argument against it.

Let me try to paraphrase what you are criticizing about ECMAScript 6 classes:

1. Single inheritance doesn’t always cut it, we need some kind of multiple inheritance (mixins/traits/...).

2. ES6 classes prevent mixins/traits/...

3. ES6’s implementation of single inheritance is ugly.

4. We have everything we need. Let’s all agree on a common, elegant library.

Comments on these points:

(1) I don’t think anybody disagrees with this point. That’s why mixins/traits/... are firmly on the roadmap for versions after ECMAScript 6. For one-dimensional taxonomies, single inheritance is perfectly adequate. If you have cross-cutting concerns, you can model them as mixins. There are many more interesting OOP mechanisms (before/after/around methods, cooperative methods, meta-object protocols, etc.). Thus, ES6 classes are but the simplest possible first step.

(2) ECMAScript 6 classes don’t prevent mixins. Certainly not in the future, but not even now – you can extend an object (instead of a function) and that object can be generated by your mixin library of choice:

    class SubClass extends mixin(SuperClass, Mixin1, Mixin2, ...) { ... }

(3) In my opinion, that’s the most valid criticism of ES6 classes: They look like object exemplars, but desugar to function exemplars. That will probably sometimes confuse people. On the other hand, backward compatibility matters! And constructors are the most commonly used and most optimized inheritance mechanism that JavaScript currently has. With more configurability coming up in ES7 or later, it is also conceivable that at some point in the future, we’ll be able to switch to a different desugaring for classes (per module).

(4) The JavaScript ecosystem suffers from a lot of NIH. If we couldn’t agree on a common library in the years since ECMAScript 5’s existence, it’s highly unlikely that it will ever happen. That’s why I think ES6 classes are so important: they enable us to exchange code between frameworks that, at the moment, have completely incompatible inheritance APIs. Object.observe helps, too, because it obviates the need for hacks to enable data binding. Similar to modules, I’m pretty sure we’d be incapable of agreeing on a common standard without ECMAScript 6.

I don’t think you appreciate how hard it was to reach the consensus for ECMAScript 6 classes (lots of incredibly long, incredibly passionate discussions!). Would I have done classes differently? Yes. But the consensus enables us to have a solution that is good enough, which (IMO) is far better than having nothing.

Dr. Axel Rauschmayer
axel at


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

More information about the es-discuss mailing list