Eric Elliott eric at
Fri Jun 28 11:31:59 PDT 2013

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.

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. =)

- Eric

On Fri, Jun 28, 2013 at 10:45 AM, Tab Atkins Jr. <jackalmage at>wrote:

> On Fri, Jun 28, 2013 at 10:42 AM, Eric Elliott <eric at> wrote:
> > I know this has been batted around already. I know everybody's totally
> > stoked about class sugar in ES6. I just wanted to register my protest. I
> > made my arguments in this talk at Fluent:
> >
> >
> >
> > I'm already seeing nasty codebase arthritis creep into JavaScript
> projects
> > thanks to things like Backbone.View.extend() being essentially mandatory.
> >
> > Providing sugar to extend classes in JavaScript proper is like officially
> > sanctioning that nonsense.
> >
> > I'm not the only one who feels that way. Here's an excerpt from one
> viewer's
> > comment on my presentation:
> >
> > "I think this will only get worse with ES6 and I am rather upset about
> it.
> > While 'class' will be elective of course, I can only imagine more and
> more
> > libraries adopting the ES6 class pattern, and then we will wind up facing
> > the same set of challenges that exist in the Java world."
> >
> >
> > In my opinion, the clamoring for class in JavaScript is because
> JavaScript
> > tries to hide prototypes, rather than make it easy to deal with them.
> > Instead of class, we should let library authors continue to experiment
> with
> > other inheritance patterns in JavaScript. Here's an example:
> >
> >
> >
> > We do need a bit more object sugar in JS, but I think we should wait for
> > some patterns to gain a foothold in the wild, and only when popular
> patterns
> > emerge and have time to be tested and proven to be well-thought-out and a
> > valuable addition (unlike Backbone's .extend(), which is causing lots of
> > problems in the real world), only THEN should the idea be blessed by the
> > specification.
> >
> > Is class a good idea in JavaScript? I say, prove it. In fact, anything
> that
> > can have a reference implementation should be proven - not just by
> > implementing it to see if it can work, but if it can be polyfilled (or
> > something like it could be polyfilled), put it in a library and see if it
> > catches on before you add it to the spec, and everybody starts to write
> > about it in their "new JavaScript features" posts.
> >
> > So far, NO IMPLEMENTATION of class in JavaScript has become a de-facto
> > standard. I think we should set the bar a little higher where a new
> feature
> > could actually cause damage to the language ecosystem.
> >
> > Until Backbone came along and made .extend() the default way to create
> any
> > Backbone object, it was very easy for a JavaScript programmer to spend an
> > entire career having never extended from an existing class. And that was
> a
> > good thing.
> Lots and *lots* of code already uses "the class pattern" is JS,
> because the class pattern is nothing more than:
> function Foo(){...}
> Foo.prototype = ...;
> Foo.prototype.method1 = function(){...}
> The class syntax just makes this super-common idiom easier to read and
> write.
> ~TJ
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list