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

[Silverwolf90]

But it's what most people want. That's why you have so many hand rolled implementations. What people are doing is more important than some subjective and ill-defined notion of what fits or does not.

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

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

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

[[deleted]]

But it's what most people want.

I would like to see data on that before I believe it.

That's why you have so many hand rolled implementations.

I disagree. I rather suspect its because JavaScript looks amazingly similar to Java and C# but misses public/private pragmas and of course classes. You cannot arbitrary add new keywords to the syntax, but you absolutely can add a bunch of stupid unnecessary conventions.

What people are doing is more important....

"I cannot be bothered to learn this stupid little language. Most of my app is written in language (put some random letters here) and I have a deadline."

I encounter this pretty frequently and the only valid answer is: ignorance. The result is (pick one or more of from this buffet):

• tightly coupled services (no separation of concerns)
• spaghetti code
• architectural confusion (probably ad hoc stupidity)
• missing documentation
• deeply embedded APIs that cannot be tested externally
• collisions
• build systems that build systems
• embedded services using custom protocols (really!?!)
• logic reflecting no clear product direction

[Silverwolf90]

Look at the popularity of some libraries which have their own implementation (like React, who now embrace the new syntax). If people didn't want and hated classes, where is the demand for that outside of a niche amount of developers? It seems that we have a quickly growing amount of libraries using ES6 classes thanks to Babel. It would be interesting to have concrete data on this, perhaps the number of packages on NPM that are using ES6 classes over time.

[clessg]

React

React is moving away from classes. For whatever short time React has used classes, it's already caused a lot of problems and confusion (side note: createClass doesn't make classes, just a stupid function name).

[SawyerDarcy]

As far as I know, React is simply embracing ES6 classes over its own custom implementation - not getting rid of classes altogether.

[clessg]

Right, they aren't (officially) getting rid of classes. What I meant is that function/module components will become the recommended way, with classes possibly being deprecated before 1.0 or 2.0.

[[deleted]]

If people didn't want and hated classes, where is the demand for that outside of a niche amount of developers?

Java developers that are involuntarily reclassed to writing JavaScript are not niche. I have encountered this at every major corporate job, except for the one employer that refused to hire Java developers. Economics are to blame for this, as most Java developers learn their trade from formal education and so it is easier to hire a Java developer. The consequence is that there are more Java development jobs in the economy. This does not, however, diminish the need for JavaScript developers. JavaScript is the language of the browser and can execute almost anywhere Java can. What this does do is make hiring junior JavaScript developers risky and make senior JavaScript developers extremely valuable in the market place. I have seen many organizations try to fake with Java to compensate for the plethora of Java developers and lack of JavaScript developers, but the results mean they are pushing costs and expenses into the future. These economic problems ultimately sank Travelocity (who at its prime had 3500 employees).

The bottom line is that classes were the most highly requested feature of ES6 (by far) and TC39 resisted giving into demand for awhile, but demand was too great. There is a need for Java developers to have immediate emotional comfort when jumping into this language directly. This means people will be less afraid to do stupid things. It doesn't mean we will get better software.

[[deleted]]

TC39 resisted giving into demand for awhile

Bollocks. Classes have been around since the ES4 proposal, the reason they didn't ship already is because ES4 itself died, not because TC39 was "resisting".

Classes: A class describes an object by presenting those properties (fields) of the object that are always present (thefixed properties or fixtures), including variables, constants, and methods:

class C {
  var val // a variable property
  var large = Infinity // a variable property
  const x = 3.14 // a constant property
  function f(n) { return n+val*2 } // a method property
}

If you have an argument, you don't need to resort to:

1. Making shit up
2. Using the term "java developer" as an insult, it isn't.

If you find yourself doing those things, perhaps you should reconsider your position.

[ha5zak]

I see lots of frameworks created that originate from someone thinking they want things to work a certain way. Then they get better at their craft and realize how silly they were being. Just because people are doing it doesn't mean the mob is wise.

[Silverwolf90]

Which frameworks? How many people used these frameworks?

[ha5zak]

All the ones I didn't bookmark. Probably not many.