[baron816]

There's nothing wrong with classes, they're just not right for JavaScript. I'm not going to claim that I'm a JS expert or anything, this is just something I've learned from pretty well established JS experts like Kyle Simpson and Douglas Crockford.

The reasons they give are that 1) you should favor composition and delegation over classical inheritance 2) classes keep you from using and understanding closure and other functional patterns and 3) you just get a lot of really weird behavior when trying to use classes in JS which results in a lot of confusion and wasted time, especially for those who don't have 10 years of experience under their belt.

Edit: Here's Simpson's take: https://github.com/getify/You-Dont-Know-JS/blob/master/this%...

[acemarke]

It's worth noting that the React team promotes composition over inheritance, and discourages any levels of inheritance past `class MyComponent extends React.Component`.

Long term, the React team plans to investigate concepts like "stateful functional components", but until then, classes are the most straightforward way of having lifecycles. The existence of ES6 classes is based on the wide range of third-party "class" implementations across the JS ecosystem, so clearly there was a desire to have them available. Since they're available, React is using them.

[linkmotif]

> but until then, classes are the most straightforward way of having lifecycles.

Huh? Why? React.createClass({}) is/was pretty straightforward. What is more straightforward about classes? All I see is more code.

[acemarke]

I was responding to a comment saying "classes are a bad idea in JS in general". `React.createClass` is a homegrown implementation of classes, React.Component builds on ES6 classes, both would be disliked by Kyle Simpson or Douglas Crockford.

There are three major differences between `createClass` and React.Component:

- Autobinding

- Mixins

- Custom class system vs one that's built into the language

Autobinding is the most useful aspect, but there's a variety of ways to deal with it: use the Class Properties syntax and write methods as arrow functions, use one of the many autobind utilities in a constructor, write your own base class that extends React.Component and do autobinding in its constructor, etc.

Mixins are now a discouraged approach for writing React code. If you still want to use mixins in React components, there's some "compat component" classes on NPM, or you could use a non-React-specific method of applying mixins.

And finally, deprecating a custom class implementation means that it's one less thing the React team has to maintain, and the lib size is that much smaller.

[tracker1]

To me, classes make more sense when you carry context with event binding, which components often do. It's syntax sugar over the Foo.prototype.* drivel, and I don't mind it...

That said, I tent to follow more functional patterns for workflows (prefer Redux and similar extension), but for some components the class syntax is usually nicer. Most components are probably best served as simple render methods though.