Something my team has to deal with on a daily basis is multi-language, multi-region contexts for presentation, data and business logic. We also run a/b/m-v tests continuously and beta test site re-designs and new features regularly on multiple sites.

This may not be a typical scenario but I’m sure there are others who share our pain points.

MDV looks good but how long do we wait?

In the meanwhile we are looking to implement server and client templating using the same model (JSON) and the same markup (Mustache spec) but thinking seriously about whether the server side app is needed at all (outside of SERP considerations).

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.