In Defense of JavaScript Classes
Cory House
10916

My biggest problem is simply the keywords “class” and “extends” … they aren’t classes, and the don’t extend (they chain). If the keywords were “prototype” and “chains” I would have been fine with them (although I’d still have my gripes about poor representations of how things happen, a lack for default data properties, inability to mix in (multiple inheritance of a sort), etc, etc.

So with all that said, I don’t disagree with a lot of your statements, except one: “Low Learning Curve”. You state that “If you’re working on a team that already understands classes, then ES6 classes are clearly easier to understand than the alternatives mentioned above.” This is a fallacy. While writing the syntax is easier to understand, truly groking what is happening is made much more difficult. When a developer that tries to only understand prototypical (-typal) inheritance through the JavaScript “class” and “extends” keywords they are going to have trouble down the road.

Yes, I know that you mention in the very next section that this is just syntactic sugar, and that it “mask[s] the power of prototypal inheritance”… but it’s more than just that. Not understanding the prototype chain can lead serious architectural flaws and extreme difficulty when debugging code.

As I said, I wouldn’t mind this so much except for the blatant hiding of the fact that JavaScript uses prototypes. This, in my opinion, is an injustice to the language and a disservice to new developers, not a helping hand.