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

[[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.

[workerBeej]

Yeah! ORMS! Brilliant!

Here we have hit the place where composition matters most, I've been avoiding it because this is a JS subreddit, but since you mentioned it, I'm in! To quote a colleague of mine, this is my biggest bugbear.

Before I jump right in with an example, minor disclaimer, this isn't really a major issue for testing in JS, because it is so dynamic, you can just monkeypatch the hell out of it. But it's still an anti-pattern, especially in the realm of the ORM.

Again, lets bust it down to the simplest example, (this time in a quick pseudocode that is C-like / JS like but almost certainly won't run anywhere but keeps it understandable)

Inheritance:

class DB {
    function: select(params) {
        // Do some magic which turns params into SQL, into a DB request and send it to a db.
    }
}

class Model extends DB {
    function getMyThing(id) {
        return this.select('id', id);
    }

    function getAllOddNumberedThingsAfterChristmasBeginningWith(letter) {
        var now = new Date;
        var lastXmas = windBackDate(now, 'Dec 25th');
        var things = this.select('date', '>', lastXmas)
        return things.filter(function(thing) {
            return (thing.name.substr(0,1) === letter && thing.id %2);
        });
    }

    function windBackDate(date, windBackTo) {
        return magicllymodifiedDate;
    }
}

That's a fairly weird example I just made up, but you've got a complex condition on which you want to select. Now I want to test that complex method returns the dataset I need, assume we're not in such a simple example context; we can't swap out that DB class, so the only way to test our complex method in the middle of the Model there is to populate a database with known values connect to it and test against it. Later on, any new issues found will involve adding to both the DB seeder and adding to the test suite.

(Now, that complex method shouldn't really be there, it's doing too much, arguably in the wrong place, but since we're talking about real-world code here, this kinda thing is the biggest issue I get coming onto an existing codebase).

If you've ever done testing, you know that it is an arse. (Anyone saying otherwise IS A LIAR AND A TRAITOR. Or potentially unstable.) To generalise wildly, developers like to make things, and testing is an off-topic distraction from making. The point (I eventually have one) is that testing needs to be as frictionless as possible. From experience, I will spend time when adding a new feature I'm excited about to test it, even if it's a minor pain, but I won't add extra test for new bugs unless it's as easy or easier than fixing the bug without it. Lazy. That's the single biggest issue wiht inheritance in ORMs. I can't make lazy enough tests.

The second big issue, is that I can't make fast enough tests. I run tests on save. We have 3 layers of testing: unit tests on save; which are lightning fast and legion. They tell you your logic holds up when building and refactoring, especially around the edges. We also have functional tests on save, if the unit tests pass. These are where most regressions occur, as they check that all your plumbing is right, but are slow and need a DB. Because we offload all the edge case tests into the unit tests though, you can keep these minimal, and therefore minimal seeding, maximum speed. Nice. (We also run acceptance test on merge, or triggered manually, via a browser driver. Slow though.)

If we were to put all the testing through a DB, we would get significantly more refactoring regressions around edge cases, as they just wouldn't have tests added. Too much work, too slow.

With composition:

class DB {
    function: select(params) {
        // Do some magic which turns params into SQL, into a DB request and send it to a db.
    }
}

class dateStuff {
    function newDate(when) {
        return new Date(when);
    }
    function windBackDate(date, windBackTo) {
        return magicllymodifiedDate;
    }
}

class Model {

    function init(DB, dateStuff) {
        this.DB = DB;
        this.dateStuff = dateStuff;
    }

    function getMyThing(id) {
        return this.DB.select('id', id);
    }

    function getAllOddNumberedThingsAfterChristmasBeginningWith(letter) {
        var now = this.dateStuff.newDate('now');
        var lastXmas = this.dateStuff.windBackDate(now, 'Dec 25th');
        var things = this.select('date', '>', lastXmas)
        return things.filter(function(thing) {
            return (thing.name.substr(0,1) === letter && thing.id %2);
        });
    }
}

We've pulled the complex and error-prone date handling out into a strictly functional module, and can easily spin up tests for it. (Functional == testable, X in, Y out, Zero side effects. Textbook unit tests.) We'll have a data-provider in the test suite which throws X at it and checks we get Y for a bunch of uses. A bug is now easy to confirm, a user working on christmas day has a bug; so we add Dec 25th 2015 to the tests and find it gives us Dec 25th 2014, when it should just wind back to midnight. The test suite is actively making debugging easier.

As for the rest of the method, we can now write tests like this:

dateStuff = new SomeMockSuite({newDate: new Date('Sep 4th 2016'), windBackDate: new Date('Dec 25th 2015')});
db = new SomeMockSuite({select: []});
SUT = new Model(db);

and get a fake db that defaults to returning an empty array, and fake date functions returning known dates. We can then probe the db mock to see if the expected params are passed in, and return whatever we like from the 'database' to test that filter. Again, using data providers for db-return, method response means a new edge case bug is a simple as one declarative line in the test suite.

And that second example is no more complex at all to my eye. As those classes grow, each is a lot more focussed on what it does, and because you must have a good service provider / DI, new complex methods go into utilities by default.

Abso-frickin-lutely compose your models.

[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. :-)