In the ES6 version, it is very clear that we are describing a class of similar-looking object that represents an Animal.
ES6 class ≠ classical inheritance
Thai Pangsakulyanont
753

A Classy Discussion

Thank you for your considered response. I’m sure a few people will learn from it.

Aside from a few trouble zones, there’s lots of good advice in your writeup.

You’re totally right that `class` is not synonymous with class inheritance, but `class` affords class inheritance, and it lures unwary developers to crash on the rocks.

The Mouse Factory

Your code isn’t doing the same thing. In my example animal and mouseFactory are intentionally two different things, frequently located in separate files, and possibly separate repos, maybe managed by entirely separate teams.

My fault, I’m sure, because I didn’t make that explicit in the example.

I would not recommend exporting a class. I can see that you know that you shouldn’t be extending classes willy-nilly, but the next dev to use your code might not be aware of that.

`class` affords `extends`, like chairs afford sitting, and balls afford throwing.”

`new` as signature is just broken. I hate that it is, because you’re right — if people just avoid the dangerous bits, it’s totally fine, but as it is, switching from a `class` or constructor to a factory often breaks lots of things in the trenches, where there are all different skill levels of developers working on things, often in separate projects and coding from separate continents.

So keeping that in mind, your version of the mouse factory would not be available.

Squeezing “composition” into a little box?:

If all you need to expose on your object is `.on()` and `.off()` from an event emitter, why make your users type `obj.events.on()` and `obj.events.off()`?

Sometimes (in my experience, usually) mixing methods and properties right into the root of the new object instead of keeping self-contained references is what is best for the API, and that is no less a valid way to compose than nesting the objects is.

React

There are better ways to build React components — ways that don’t beckon inexperienced developers to misuse. My advice: Just use those instead and save yourself the trouble.

Hope

There is a proposal for callable classes. If we could use those and disallow `new`,`extends`, `instanceof`, etc.. in our lint rules, I’d soften my approach to `class`.

Reality (for now)

Barring the discovery of any really compelling reason to use `class` instead of a factory or the many composable alternernatives, I just don’t see any good justification that makes it worth the risk and the trouble.

But use `class` if you can get some perf

That said, if you want to use class internally, and export a factory, that could give you some perf gains, so maybe there’s one valid use-case for `class` after all.

Show your support

Clapping shows how much you appreciated Eric Elliott’s story.