[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.