Classical inheritance is obsolete

Dmitry Soshnikov dmitry.soshnikov at
Sun Jun 30 00:11:33 PDT 2013

I agree, this topic fits better for JS forums. There is no big need to
discuss here "prototypes vs classes" (it's simply about code reuse with
different styles, and is searchable on many JS forums/articles). This
mailing list is for the language design and implementation.


On Sat, Jun 29, 2013 at 7:07 PM, Axel Rauschmayer <axel at> wrote:

> 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
> home:
> twitter:
> blog:
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list