Douglas Crockford says that classes were the single worst mistake in es6. So it's not really a face palm:
Beyond that I'd argue that classes give you more guarantees about how an object will behave at the expense of flexibility, although they give you escape hatches if you like. The reduced flexibility is really nice because you can define safe subsets of the language in which tools that analyze and refactor code are possible, even across files if you're using the module system. Moving the language in a direction where consistent universal tooling is possible to write is something that I love about classes, and is often overlooked in discussions about it. I don't care that classes are just a simplified subset feature of what's possible using prototypes, it covers the common case well enough and makes it possible to write really nice code completetion and refactoring tools that don't randomly break. That's worth all the extra magic in my opinion.
function Animal() {}
function Cat() {}
Cat.prototype = Object.create(Animal.prototype);
(function(fields) { fields.forEach(function(field) { Cat.prototype[field] = function() { // Some nonsense }; }); })(['what', 'the', 'hell']);
It's impossible to statically infer what methods are being declared in ES5 code in general. You can pick up on some common assignment patterns, but not all the weird stuff people do. Just check out the top 10 NPM modules and I guarantee you'll find some odd assignment patterns. I can remember that the "colors" module did meta stuff when I last checked. You can't just easily run the code to find out what the module is exporting either, because of potential side effects from IO. You can wrap Node's core IO modules, but that solution is specific to Node, and still won't cover every possible case. In short, it's a huge pain to write tools to pull information out of Javascript code in general, and that hurts the tooling ecosystem around Javascript.
With the class pattern you at least have some staticly inferable information you're sure you can pull out of the class, and weird stuff is discouraged. I know in some ways that this is a weak argument, because of the new square bracket assignment, and the fact that anyone can muck with the prototype of the class after it's created. Even still, for the simple OLOO case it does encourage people to write code that has method names that can easily be staticly inferred, and that's a good thing for JS tooling possibilities.
I really just want omnicompletion that doesn't randomly break on me! The OLOO pattern is one that's incredibly common in JS
Is Crockford's dislike still based on this: http://www.crockford.com/javascript/inheritance.html ?
Because I don't quite buy into that line of thinking. I'm really looking forward to webassembly…