There's very few things JS classes can do that ES6 modules/named exports along with closures returning plain objects can't do better, in term of code organization, isolation, and extensibility. For the 6 times a year where I need an actual class (it does happen!), I can write the prototype code.

The main issue with adding classes is that they're very, very complex if you want to make them useful. The initial version was pretty harmless, but it was also almost pointless. Now they need to back fill all of the missing features (eg: private fields), which brings in an enormous amount of complexity. Most of the time, if I need private fields, I can just use symbols (not quite private, but close), or I can do

function() { let private = 123; return { // use private in functions here } }

It adds (there ARE things classes are better add) very little compared to the insane amount of work that has to be put in the language to get it all working. Decorators are in a similar boat, where many decorator usages can be expressed just as easily with a higher order function, so adding the extra syntax is just bloat.

The cost isn't worth the reward.

The biggest thing classes give us that is very difficult to replace in vanilla javascript is a semantic construct that is easy to statically analyzed. In the typed flavors (Flow, TypeScript), I can analyze the interface of plain objects, but not in vanilla JS. Part of why React using ES6 classes can be useful.

Thats a great benefit, but Im not sure it's worth the trouble.

> There's very few things JS classes can do that ES6 modules/named exports along with closures returning plain objects can't do better

That's a really good point. I was about to disagree with you but then I created a thought experiment.

Thought Experiment:

I wonder what the JS landscape would look like if ES6 Modules were introduced as part of ES5 about 8 years ago? I could definitely see how that would make classes fare less appealing if we already had a great module system (sure CJS existed but browser didn't support it).

Looking at the timeline of when these features were implemented in all major browsers:

* ES6 Class[0]: implemented 2.5 years ago * ES6 Modules[1]: implemented 1 month ago

[0]: https://caniuse.com/#feat=es6-class [1]: https://caniuse.com/#feat=es6-module

And ES6 classes were designed long before they were implemented, around the time people were making class hierarchies with backbone and AMD modules were the future.

The rise of Java and the OOP revolution isn't that far behind us (2 decades seems like a lot in the tech world, but its still within a single generation of humans).

>In the typed flavors (Flow, TypeScript), I can analyze the interface of plain objects, but not in vanilla JS.

I've found that developing JavaScript in an IDE that reads and validates type information from JSDoc allows me to introduce strong typing while maintaining the flexibility and simplicity of vanilla JavaScript without getting as bogged down as I get with Typescript.

For sure, though my comment referred more to analysing code for things like automatic transformations at scale (like codemods) than during development. Like, figuring out that a stateless function component is a component is hard.

You can do almost everything with jsdoc comments in flow and TS, of course. It's awesome.

ES6 classes were such a relief compared to the prototype bloat you had to right. I love syntactic sugar that makes my life easier.

ES6+ flavors of JS & Typescript really made me take web programming seriously again.

I loved the classes at first, but as I've got more in to it I've found that classes and prototypes are redundant. Closures let me maintain all of the state that I need without the extra boilerplate.

Agreed, classes with typescript and Vue make sense to me in a SFC approach.

Something about components just fits the class model well.

Or, you know, you could actually learn the language you use. Prototypes are not nearly as bloated as classes, and you usually don't even need them. OO is not the one true paradigm of coding.

also agree, would not go back. TypeScript is savage