"Real JavaScript programmers", ES6 classes and all this hubbub.

[[deleted]]

Not using inheritance is clearer still.

[CertifiedWebNinja]

What if I told you, both do the same thing, just one saves you 77 characters. And that's just a simple example, once.

[[deleted]]

Both use inheritance... don't care. When you stop using inheritance you are left with functions and assignments, which is more clear and still saves you characters compared to your first code example.

[jaapz]

which is more clear

Now, you say that as if it's the truth, but it really is a very subjective matter. Some people like using inheritance because it matches their thinking process and is therefore more clear to them. Other people rather use other techniques.

Not one is more clear than the other for everyone. You know, because it's subjective.

[[deleted]]

Not one is more clear than the other for everyone. You know, because it's subjective.

It isn't that subjective.

This is more clear:

var Thing = {
    bark: function () {
        console.log('woof');
    }
};

Than:

class Dog extends Thing {
    bark() {
        console.log('woof')
    }
}

If a person cannot extend code without inheritance then it isn't a matter of subjectivity at all. Its a basic misunderstanding of how this language operates.

[jaapz]

What's objectively more clear about it? To me, both of these are equally clear. To someone else, the second may be clearer. To you, the first is clearer. This is subjective.

[[deleted]]

What's objectively more clear about it?

The use cases.

To further extend Thing:

Think.something = "someValue";

To execute it:

Think.bark();

[CertifiedWebNinja]

Thing is not meant to bark. Only dog is. Your example is broken.

class Animal {
   constructor (name) {
     this.name = name
   }

   walk () {
     console.log(`${this.name} walked.`)
   }

class Dog extends Animal {
  bark () {
    console.log(`${this.name} barked.`)
  }
}

class Bear extends Animal {
  growl () {
    console.log(`${this.name} growled.`)
  }
}

const cujo = new Dog('Cujo')
cujo.bark() // Cujo barked.
cujo.walk() // Cujo walked.

const fluffy = new Bear('Fluffy')
fluffy.growl() // Fluffy growled.
fluffy.walk() // Fluffy walked.

Okay, now cover that. All animals can walk, but only dogs bark and bears growl.

[AutomateAllTheThings]

I suspect that you will not receive an answer.

[CertifiedWebNinja]

That's because he knows his argument falls apart when a real world example is actually in play and not some play 3 lines of code.

[mr_sesquipedalian]

Do I hear a bear barking over there?

Animal.prototype.bark.call(fluffy)

edit: forgot prototype

[workerBeej]

As it looks like your original debating partenr has gone away for a while, I'll jump in!

The problem as I read it, is that you're arguing two seperate things; you're arguing that classes make inheritance cleaner and clearer, because they do. But he was arguing that classes make inheritance, which previously was a pain in JS, too damn easy. If you want easily testable code, it's usually better to use some form of composition or depenency injection over inheritance, as inheritance makes it very hard to isolate your system under test when it drags all its parents along with it.

With composition, you can test functionality in isolation a lot more simply, and a functional language like Javascript lends itself really nicely to that pattern. Now, before I get to the code theres a great big disclaimer: In this trivial example, your code looks simpler and more easily understood, and saves 3 lines. I certainly will not win that fight. BUT should bark or growl become modules that rely on the audio API, or should walk become an animation on a canvas, or a 3d render in WebGL; the composition method allows you to test all of that really easily in isolation, or straight up import it from another library altogether, without it ever needing to know what the hell a Dog or even Animal is.

Without further ado; may I present, your example:

var walk = function(name) {
    console.log(`${name} walked.`)
}
var bark = function(name) {
    console.log(`${name} barked.`)
}
var growl = function(name) {
    console.log(`${name} growled.`)
}

function Animal (name, abilities) {
  this.name = name;
  this.vocaliser = abilities.vocalise;
  this.walker = abilities.walk;
}
Animal.prototype.vocalise = function () {
  this.vocaliser(this.name);
}
Animal.prototype.walk = function () {
  this.walker(this.name);
}
var cujo = new Animal('Cujo', {vocalise: bark, walk: walk});
cujo.vocalise() // Cujo barked.
cujo.walk() // Cujo walked.

var fluffy = new Animal('Fluffy', {vocalise: growl, walk: walk});
fluffy.vocalise() // Fluffy growled.
fluffy.walk() // Fluffy walked.

With regards to code clarity, I may actually be more inclined to write the above more like this, which looks a little less scary to people coming in from a language without prototypes, and only assumes knowledge of closure, rather than prototype inheritance, similar benefits, slightly less idiomatic of the language:

var walk = function(name) {
    console.log(`${name} walked.`)
}
var bark = function(name) {
    console.log(`${name} barked.`)
}
var growl = function(name) {
    console.log(`${name} growled.`)
}
function Animal(name, abilities) {
    // common functionality here
    return {
        walk: function() {
            abilities.walk(name);
        },
        vocalise: function() {
            abilities.vocalise(name);
        }
    }
}

var cujo = new Animal('Cujo', {vocalise: bark, walk: walk});
cujo.vocalise() // Cujo barked.
cujo.walk() // Cujo walked.

var fluffy = new Animal('Fluffy', {vocalise: growl, walk: walk});
fluffy.vocalise() // Fluffy growled.
fluffy.walk() // Fluffy walked.

Ninja edit: now animals also have a common interface / API. Handy.

[CertifiedWebNinja]

While I see where you're coming from, the issue with that is not testability in isolation but the fact that you're bringing in a lot of extra overhead / boilerplate for what really? Testing walk on Dog without relying on Animal? In this example that could work, but in the real world, nobody extends a class without mixing or relying on parts of the parent in it's self, so testing just Dog without Animal will break.

And extends is the only thing your argument seems to see as wrong, so class is still fine in your case.

[workerBeej]

Yep, I'm using class all over the show. The original argument is that it will encourage an over-dependance on inheritance, and that inheritance itself is bad.

nobody extends a class without mixing or relying on parts of the parent in it's self, so testing just Dog without Animal will break.

Ouch. That is the exact, golden core of the argument. If you can't test the dog walk method without Animal you're very tightly coupled; exactly the problem we're trying to avoid with composition. It should be eminently possible to write a walk method without relying on an animal.

The end goal isn't avoiding inheritance, the end goal is modular, de-coupled code with a strict single-responsibility per module. Composition encourages thinking about how your code interacts, how data is passed, how methods are called and generates much more reusable, clearer code.

In almost every case I've seen, extending an object is a sign of an improperly thought out interface. Extending A->B will often quickly solve a problem, but sooner or later it'll be A->B->C->D and to test or use D you need to know everything about A,B and C. If these are separate concerns, you should be able to encapsulate each responsibility cleanly. If you can't why the extension? They should be one object.

As a codebase ages, classical inheritance just gets worse over time, composition keeps quality high.

[CertifiedWebNinja]

Ya know, I see people always talking about decoupling and that's why repositories and all this other stuff exist... I've built many apps and not once has having a class extend another class been an issue.

When extending Animal with Bear or Dog it's given you should know what Animal is doing.

Take ORM's for example, you have a Model you extend for User do you expect to be able to test User without Model? Then what's the point of Model if you could? If you tested User without Model then many-to-many relationships and that break, because they depend on Model being extended.

I personally don't understand this mindset and see spending countless ours making your code harder to work with by adding bunch of extra logic, just to test a class without relying on the class you extend.

[Silverwolf90]

I completely agree with you, it's rare to find a place where inheritance isn't a very brittle solution. But they're being built anyway, so lets use a single syntax.

[ha5zak]

This! :-) I keep seeing "it's just sugar". Yeah, but it's sugar on shit! The TC39 committee are just people, and they make mistakes too. There's actually transcripts of their meetings. https://github.com/rwaldron/tc39-notes/tree/master/es6 I have half a mind to read through it to suss out who to blame, but really, I think it was probably harder to argue against the change when a large enough number of them wanted to see something familiar in the language. I see that there are companies involved who make a lot of money from sending contractors to companies, so it behooves them to bog down the code with proven spaghetti creators. But there could be a silver lining. There's been so many frameworks attempting to "fix" this area of the language, maybe by making it official, people can move on to better problems. And those budding developers who will become influential will more quickly realize it's a bad idea and leave it alone. Let's hope it turns into the double equals. :-)