You should never be using `.constructor` anyway because it isn't reliable because a very common pattern replaces the `.prototype` with a new object who's `.constructor` is `Object`
var Foo = function () {};
Foo.prototype = {
bar() { return 'bar'; }
};
var f = new Foo();
f.constructor === Object;
When you use `class` you are still messing with `.prototype`. The danger is that programmers new to JS don't understand that they are and don't understand why that matters.
Calling `super` is very anti-pattern in JS. Unlike classic OOP, parents are not static. Lots of very common things can rip that rug out from under you by modifying the parent in many different ways (createProperty, Symbols, proxies/reflection, etc).
Static methods do indeed exist without classes.
class Foo {
static bar() { return 'bar'; }
}
//is identical to
function Foo() {}
Foo.bar = function() { return 'bar'; }
If you use `Object.create()` and ES6 object literal syntax you don't have to type `function` either. You get the added bonus of being easily able to wrap it in a normal function that avoids constructor weirdness
var someProto = {
bar() { return 'bar'; }
}
var myInst = Object.create(someProto);
I'm actually a fan of the class syntax, and use it regularly.
>no need to even type function for methods
However, to be fair, you can do this with object method shorthand now:
const deepThought = {
theAnswer: 42,
tellTheAnswer() {
return `The answer to life, the universe, and everything is ${this.theAnswer}`;
},
};
deepThought.tellTheAnswer(); // => 'The answer to life, the universe, and everything is 42.'
Which is also quite elegant. I think they both have their places depending on the program. I think it depends on readability needs at the time, and whether an instance is better than just a container in that circumstance.
Is it really simpler? Let's say you take two equal students with zero knowledge of programming and teach classical to one and prototypical to the other. Would the student learning classical inheritance grok it faster? I doubt it.
I do agree that it is easier to understand the new syntax if you have experience with a language that use the same syntax. However, that's not learning anything new. It's simply using concepts that you already know.
Prototypical inheritance may seem simpler at first glance. But understanding how to use it correctly can be extremely difficult, even for experienced JavaScript developers, mostly because there are so many different ways to achieve almost the same thing, but with subtle differences. For example, you can reuse a single object instance as a prototype for multiple others. Or you can create a new instance of the prototype for each instance of the child. The two are similar, but affect e.g. whether or not properties in the prototype are shared or unique.
In the past I've eventually resorted to copy and paste the same template every time I wanted to use inheritance with prototypes. With classes, I never have to think about these problems anymore. There is one way to define a class, and it always works like I expect it to.
But that's the metric everyone uses to gauge a language.
Look at all the complaining about Lisp and Rust syntax which boils down to "ugh, this is unfamiliar."
But to answer your question, I think they are both within a pebble toss distance of each other. But still much harder than other languages due to `this`. `class` just unifies some patterns people were doing like inheritance.
Calling `super` is very anti-pattern in JS. Unlike classic OOP, parents are not static. Lots of very common things can rip that rug out from under you by modifying the parent in many different ways (createProperty, Symbols, proxies/reflection, etc).
Static methods do indeed exist without classes.
If you use `Object.create()` and ES6 object literal syntax you don't have to type `function` either. You get the added bonus of being easily able to wrap it in a normal function that avoids constructor weirdness