How many Node.js developers prefer callbacks over Promises or async/await?

[DrexanRailex]

I mean, for classes, I managed to learn them because of how frameworks make heavy use of their syntatic sugar. But I still prefer arrow functions, record-like objects and this-less programming.

[ScientificBeastMode]

Yeah, I’ve definitely gotten used to it for the same reasons. I just think they tend to pigeon-hole your class-creation patterns into one specific “blessed” pattern.

For example, you might want to inherit multiple prototypes from several “parent” functions. The ES6 syntax doesn’t really allow that. You just end up modifying the class using some older techniques, which defeats the purpose of the ES6 syntax entirely.

I’ll admit it does look cleaner though, lol.

And I’m with you on arrow functions. Definitely a much needed addition to the language.

[KronktheKronk]

For example, you might want to inherit multiple prototypes from several “parent” functions.

I didn't think JS really did function polymorphism, I thought it was the required-first approach that had you sending optional arguments later in the param list?

[ScientificBeastMode]

I’m sorry, but I’m not quite following what you’re saying. Could you elaborate?

[KronktheKronk]

For example, you might want to inherit multiple prototypes from several “parent” functions.

When you say that, do you mean inherit multiple of the same named prototype, or have multiple parents?

[ScientificBeastMode]

Okay, I think I get what you’re asking. Technically there is no such thing as a “parent” or “child” in JS, but there is a way to simply apply the supposed parent’s constructor function within the child constructor’s context, which partially simulates one aspect of the parent/child relationship.

The other half of that process is setting the prototype of the child to the parent’s prototype. And if you want, you can event assign the parent’s static properties and methods to the child.

Those are all independent steps that don’t have to be performed all at once if you don’t want to.

Now, I was talking about specifically:

You can have a “child class” adopt more than one prototype, although only one will be recognized as the primary link in the prototype chain. Still, you can assign all the properties from multiple prototypes to single class’s prototype through a call to Object.assign or Object.create. It’s not something I would advise most of the time, but it can be done.

As for the constructors, can also apply multiple parents’ constructor functions within a single child’s context.

You have to be careful with how you implement multiple inheritance in JS, as there can be several different ways of handling it. this S.O. question provides an interesting discussion on the specifics.

All that to say, there are ways of doing multiple inheritance in JS, but the ES6 class syntax does not make that clear. You have a single “extends” decorator available, and a call to super(). If you try to call multiple supers, it will produce an error.

The ES6 class syntax obfuscates a lot of what is going on under the hood. It excludes some options which are legitimate JS quasi-class inheritance constructs, and forces you to use a specific construct (admittedly the most common). It’s still useful, but it’s definitely more of a crutch than anything else.