Tab Atkins Jr. jackalmage at gmail.com
Fri Jun 28 10:45:48 PDT 2013


On Fri, Jun 28, 2013 at 10:42 AM, Eric Elliott <eric at ericleads.com> 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:
>
> http://ericleads.com/2013/06/classical-inheritance-is-obsolete-how-to-think-in-prototypal-oo/
>
> 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:
>
> https://github.com/dilvie/stampit
>
> 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


More information about the es-discuss mailing list