First, please don’t talk like that. Second, if you are keeping the JS way of doing objects (prototypes, etc) in short-term memory, you are doing it wrong.

I realized, maybe if I have to deal with mayonnaise, why not just try making an equally tasty sandwich with the new ingredient?

“Don’t add classes and the world at large thinks of JS as a joke and a toy” — so because we have a “new generation” of classically-trained programmers who are using Javascript we need to add a “class” keyword so they don’t feel so weird about prototyping? I’m one of those programmers. I got over it, so can they.

The ECMAScript 5 spec addressed A LOT of the issues I have personally with prototyping. I cannot wait until its adopted across the board.

I think creations like Coffeescript (and dare I even say Dart) have put the web app development world in a frenzy over shimming every classical OOP pattern into Javascript (or in the case of Dart, dropping JS altogether). I think this post highlights a critical fork in the road.

On browser population, trust me; I feel your pain. It’s the reason I’ve spent years of my life trying to provide us all with a workaround in the form of Chrome Frame. I get that none of this stuff really matters until we can fix the decay rate of Old IE, and I’m still working to make that better. But we can’t just do nothing while we wait for the cavalry to arrive, else we’ll be empty handed when it *does* get better and have nothing to show for our hard-won victory.

I don’t doubt what you’re saying. I just doubt that adding a “recommended” version of classes is going to solve it. These various class libs all do things differently because that’s how their authors want to solve the problem. And through conflict and fear of backwards incompatibility, we’ve ensured that class syntax can be ignored, extended or co-opted for the same nefarious purposes. I think there will be some adoption of the class syntax and some reduction of ad-hoc solutions. But as long as it doesn’t do what some people expect, javascript is still flexible enough for people to do their own thing.

All that being said. This may still be good enough. More important than anything is making it possible for devs to adopt the new syntax sooner rather than later. That story is getting better for browser apis, but not so much for js upgrades. New js syntax is still just not feasible for the wide majority of browser devs. This may seem like a lame argument, but it has consequences in trying to gain support for this stuff. What it means is that the support you might otherwise get isn’t there because most practical devs just don’t care. Because they know it won’t make a difference for them for a while yet.

Your example still doesn’t work. The Color function object (aka “class”) delegates to something other than Color.prototype. In this case, that something is Function.prototype. That means that you can’t de-reference Color.WHITE unless you add it to the function object directly (as you did above) as a “static”. That’s allowed.

What adding things to Color.prototype.* does is make them available as things you can de-reference on instances of Color. Here’s a quick example showing what works:

class Color { constructor() { ... } }
// Class-level data (aka, "statics")
Color.WHITE = 0xffffff;
Color.blend = function(c1, c2, alpha) { ... };
 
// Prototypal method
Color.prototype.blend = function(other, alpha) {
  return Color.blend(this, other, alpha);
};
 
// Now, usage:
let c1 = new Color(...);
let c2 = new Color(...);
let b1 = Color.blend(c1, Color.WHITE, 0.5);
let b2 = c2.blendWith(c1, 0.5);

Does that clear it up?

I’d be on-side with you if we didn’t have *enormous* piles of evidence to suggest that people are already staring down the complexity you’re accusing us of adding, but doing it in an ad-hoc, non-interoperable way. Nearly every JS library includes some form of class system (yes, even jQuery via jQuery UI). If we weren’t simply codifying something you demonstrably need, I think your critique would be more relevant; but as it stands, we’re overdue for this. The complexity exists, people are already struggling with it, and there’s an opportunity for the language to do something reasonable to help settle the various style/pattern/library wars around classes.

I have some sympathy for the idea that we should use a name other than “class”, but doing that would prevent us from introducing them in non-module or opt-in environments and would make whatever the alternative keyword is contextual. That’s going to force developers to know that they can only use these newfangled object factories in some contexts but not others, adding mental overhead.

With javascript, any new framework you look at will have its own way of defining something like a class. They’re trivially different and they haven’t really evolved at all in the past few years. This makes them ripe for standardization IMO.

My only concern is that the underlying prototype still be exposed to those who know what they’re doing. Also, classes should be mutable by default, just like everything in JS, but I guess if people want to “freeze” objects that should be easy enough too. Overall, the maximally minimal classes proposal seems to capture all the right behaviour pretty cleanly. +1

A not-crazy example might be what amounts to an enum.

class Color { … }
Color.prototype.WHITE = 0xffffff;
Color.prototype.RED = 0xff0000;
Colo.blend(Color.WHITE, 0xff00ff, .5);

I’ve also used class variables for caches and the ilk as well.

I’m perfectly happy declaring them in foo.prototype.blah form (as opposed to within the class block). I was confused because your comment seemed to indicate that one wasn’t able to have prototype level data.

Everybody — even having a *bleh* syntax for classic OO classes, even if it’s just sugar, is a win in that we don’t have to ship a convenience function down the wire, and classes from multiple sources can interoperate. Think of it as “querySelectorAll” for object designs.

But I would like to throw this into the discussion. What I’ve been arguing lately about es.next proposals is that they may be adding wins to the language, but they are also adding complexity and confusion. See my post about fat arrow and the ensuing discussion (would love to have your thoughts there as well).

The problem with something like classes is that while it follows all the basic rules of js, it presents them in a new syntax that creates dissonance. So a class has to desugar to a function with prototype methods. So the constructor inside it is a different construct? Does the prototype live on the class or on the constructor? If I get an instance from this class, can people mess with that instance or can I count on it always being what it’s supposed to be? I know the answer to these questions, but I argue that they are not obvious to someone learning the language. They are not obvious to someone coming from another language with a stricter definition of how classes behave. That’s why I can sympathize with the argument from your colleague.

The question is, if we don’t expect people to be able to build a working mental model of these constructs and reason about them sufficiently, then what is their purpose? If we introduce a class that falls all over the traditional prototypal usage and also falls all over the OO mindset that some are almost certainly going to come into this with, where is the win? How is it not just another point of confusion.

My example of this is the concept of dynamic this. It’s close enough to OO to seem familiar, and then it has this wildly different behavior that people are still tripping over decades later. I don’t know what the pitfalls will be of these class proposals. But I calling them classes at all is just asking for trouble. I don’t have another name that might help to disambiguate. At least “module” is sufficiently generalized and doesn’t come with baggage.

Not sure if I’ve been clear here, but those are my thoughts. In the end I agree that we need consensus more than perfection.