[gavinpc]

I felt the same way and avoided `class` for mostly the same reasons.

For better or worse, there are many ways to make pseudo-classes using Javascript. Is prototype configurable? Writable? Enumerable? What about the properties of prototype? Are they configurable? Enumerable? Writable? And there are still people who clobber the default prototype, killing its `constructor` and changing the above.

And that's just one level. When it comes to calling super constructors and super methods, things get much wilder.

I've come to terms with the view that ES6 classes are just a way for us to move on with our lives. We do a common thing in a common way, and never think for a second about what subclassing approach to use, what method is compatible with what other method, and whether it's implemented correctly.

Yes, you need a build step to target older browsers. But you needed a dependency anyway, to support whatever ad-hoc method you were using.

I never used mixins, but I agree that HoC's present a special problem for testing.

[algesten]

I'm one of those people that still use coffeescript (if I'm going to transpile anyway, I'd rather use a language I like).

I use coffeescript classes as components without any problem and that inserts an "extends" function into every compiled .js-file that has a class.

I suspect people that need ES5/ES6 compatibility that currently rely on React.createClass as a peer dependency can switch to maintaining their own createClass function local to the project. Suboptimal, but not a lot of code.