Summary: prototypes as classes

Axel Rauschmayer axel at
Tue Jun 28 18:33:59 PDT 2011

Sorry for dragging this out. The following should be my last email in this thread.

> The prototypes-as-classes approach makes new C(a,b) invoke C.constructor(a, b) with extra rules for object return value, which is a complexity. Especially for abstractions that want to be callable without 'new' to construct a new instance (Array, e.g.).

That is complexity that is added to make things compatible with constructor functions and current built-ins. If you have to factor that in, then it is indeed hard to argue in favor of prototypes-as-classes.

I don’t particularly like that most things are constructed via new, but that in a few cases, you can omit the “new” if you want to. I’m also trying to avoid the Array constructor (e.g. there is no way to create arrays such as [3] with it).

But I do understand that that’s how it is, that people use it and that there is nothing one can do about it.

If I summarize my perceived advantages as follows, then it becomes clear that they might not be worth the trouble of having two kinds of classes:

(1) Simpler instanceof (Contra: no need to look under the hood)
(2) Simpler subclassing (Contra: not needed very often, super-references make most of the advantages go away). Minor inconvenience: having to set up C.prototype.constructor in the subclass.
(3) Inheritance of class methods (Contra: I’ve only seen one case where this mattered – an inheritance API with an extend() method. Contra: property name pollution where constructors are currently used as namespaces).

Looking at these points, it becomes clear that with class literals as syntactic sugar, we get all of the advantages of prototypes-as-classes, without their disadvantage of having to support two kinds of classes. However, class literals are still a move away from the constructor as the dominant construct (conceptually, – nothing changes under the hood).

Dr. Axel Rauschmayer

axel at


More information about the es-discuss mailing list