[Styleguide] ES2015 classes

[Bargs]

I guess I don't have enough conflict in my life, so I decided to start a discussion about classes.

I felt ambivalent about classes for awhile. At first they seemed like fairly benign syntactic sugar. I tried to give them a shot, and I regretted it. I think we should avoid them entirely for the time being. I jotted down a few reasons in the styleguide but I wanted to keep it concise, so I'll elaborate a bit here.

My #1 problem with classes is that they make encapsulation impossible. Not only do they not provide a way to create private members, they also prevent you from hiding private instance members inside a closure. To me, this is reason enough to avoid them. What's OOP without encapsulation?

Classes encourage inheritance. Older languages with classes learned long ago that its better to favor composition of inheritance. Inheritance is only really useful if you have a type system, and ES2015 classes aren't types.

It's generally a best practice to avoid the new keyword. Classes require use of the new keyword. The new keyword is rigid and ties callers to a specific type of object instantiation. Again, older languages with classes have learned to prefer factory functions over constructors because they're more flexible and more powerful.

What benefits do we get for all of these negatives? Slightly fewer characters? I might have said better static analysis, but my editor seems to parse old school constructor functions just as well as classes.

Some links for further discussion:

https://medium.com/javascript-scene/how-to-fix-the-es6-class-keyword-2d42bb3f4caf#.msy3xzais
http://christianalfoni.github.io/javascript/2015/01/01/think-twice-about-classes.html

[cjcenizal]

I completely agree with most of your supporting arguments:

1. Prefer composition over inheritance.
2. Use encapsulation effectively (to present a clear and simple interface).
3. Avoid use of new when a factory method provides a more intuitive or flexible construction interface.

But I also don't think prohibiting the use of class will necessarily help people use encapsulation effectively, use the factory pattern effectively, or prefer composition over inheritance. If those are our goals, then I think our best shot is to list those bullets as desired traits in our codebase, with links to useful resources, and then refer to them in code review.

I also think a problem with prohibiting language features is that it risks becoming dogmatic... I've found it's easy to lose sight of the end goals with such broad-stroke rules, and it creates a barrier for great use-cases for the outlawed feature, which may be discovered by brilliant minds in the future.

[tsullivan]

I'm with you here, especially in regards to the point you raised about lack of private members. Whenever I've started out using classes, I've always been happier refactoring the code to use an enclosure that keeps data private, and not use new and avoid this.