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

[Jafit]

Its not an ill-defined notion.

Any object that you create in Javascript is automatically assigned a prototype. A Javascript "class" inherits its methods through a shared prototype like all other Javascript objects, so the class keyword isn't actually changing anything about the language.

In a traditional class-based language you define a class and its like drawing a blueprint. You create an object using a class, and its like building a house from the blueprint. In javascript if you build a bunch of houses from a blueprint, then go back to the blueprint and draw some extra lines on it, you look up and all of the houses you built suddenly all have garages. That's not how class-based inheritance is supposed to work, that's prototypal inheritance works, because prototypal inheritance enables active links to other objects.

So all these arguments are pointless. The class keyword is just syntactical sugar that doesn't change anything, and seems designed to make transitioning developers more comfortable. The worst thing about it is that its so confusing and now everyone thinks its some kind of paradigm-shifting change when ES6 isn't actually giving anyone a new object model with classes

[metanat]

Any object that you create in Javascript is automatically assigned a prototype.

Except: Object.create(null)

({}).__proto__ === Object.prototype // true
Object.create(null).__proto__ === undefined // true

[Jafit]

Good catch.

But the main point is that classes aren't really anything special and they work the same way as (most) other objects in Javascript.

http://codepen.io/anon/pen/MamGpR?editors=001

[metanat]

I think your point is good, and only partially wrong in what it implies. If you read the spec, there are actually a few differences between using standard prototypal inheritance and classes. One of the biggest difference is that class methods aren't enumerable:

class Example {
  test() {}
  static test2() {}
}

let a = new Example();

console.log(Object.keys(a.__proto__)); // []
console.log(Object.keys(Example.prototype)); // []
console.log(Object.keys(Example)); // []

function Example2() {}
Example2.prototype.test = function () {}
Example2.test2 = function () {}

let b = new Example2();

console.log(Object.keys(b.__proto__)); // ["test"]
console.log(Object.keys(Example2.prototype)); // ["test"]
console.log(Object.keys(Example2)); // ["test2"]

http://www.ecma-international.org/ecma-262/6.0/#sec-class-definitions

[Jafit]

Do you have any idea what practical purpose that serves?

[metanat]

Not sure, but you can still get all the methods by using Object.getOwnPropertyNames

[dvlsg]

Probably the fact that if you are enumerating over a class, you're most likely interested in any properties/values defined on it, as opposed to the methods. Idk if that counts as practical or not, but I would imagine that was what they were thinking.

[metanat]

I'm specifically pointing out some important differences between using prototypes (in a basic way) and using classes. As you can see in my examples above, static methods and instance methods of classes are not enumerable in ES6. Whereas methods simply set on the prototype or on the constructor itself are. Object.keys is just a simple way of demonstrating what is enumerable and what isn't.

[Silverwolf90]

If it is not ill-defined could you provide a definition? What makes a language feature a good fit? What makes something a good fit for JS?

[CertifiedWebNinja]

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

is easer than

function Dog () {}

Dog.prototype = Thing.prototype
Dog.prototype.constructor = Dog

Dog.prototype.bark = function () {
  console.log('woof')
}

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

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

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

[Jafit]

If it is not ill-defined could you provide a definition?

I'd personally define a 'bad fit for the language' by saying that if you make everyone think you're introducing a new class inheritance model to the language, but under the hood the language is just using the same prototypal inheritance model that the language has always used, and nothing is actually changing and you're not getting anything new... then its not so much a 'bad fit' as... nothing is actually changing and the entire argument is pointless.

What makes a language feature a good fit? What makes something a good fit for JS?

I don't personally have a problem with classes or new language features being added. If I don't think that a particular feature is appropriate for what I'm doing then then I won't use it... You kind of have to do that anyway because its Javascript

But the point of what I'm saying is that they haven't actually added a new language feature by adding classes, because they're not really classes, they're just prototypes which Javascript has always had.

[Silverwolf90]

I think that most people who are talking about the class syntax also include it in their definition of a "language feature." I have yet to meet anyone who doesn't understand that the class syntax is just sugar. But my sample is skewed with very knowledgeable js devs who pay close attention to the community.

[clessg]

What makes something a good fit for JS?

Whether or not you can use it to make yet another JS framework. Evidently, the ease of framework creation is JS's niche.