Interesting to see this implemented as a mixin when they just announced yesterday they are fully supporting es6. Looking forward to building some side projects with this and seeing how it compares to using react + flux.
We were trying to keep our API surface area small with one way to load data into components, but you're right -- we should probably /also/ add a ES6 base class as a second option, and let the people choose which they prefer.
A lot of React developers still prefer mixins -- react-router recently switched from mixins to ES6 classes and then changed their mind "until ES6 classes have better answers to replace what mixins do (like decorators).": https://github.com/rackt/react-router/blob/master/UPGRADE_GU...
Please provide a higher-order component or ES7 decorator (assuming ES7 will be supported?), would rather not use inheritance.
Even if you like classical inheritance, the Class keyword is poorly implemented for it, from both a normal OOP language's point of view OR from a prototypal inheritance point of view. It's bad at both.
The primary reason a significant part of the community hates the ES6 classes is that the class keyword is misleading for people who don't understand prototypal inheritance.
The OOP vs FP divide is orthogonal to that as the FP devs in question generally disagree with the constructor+prototype pattern to begin with (and often shun prototypal inheritance entirely).
There's also the people who want JS to be more like Haskell/Lisp, but they've mostly moved to LiveScript and ClojureScript and only occasionally complain from the sidelines.
You forgot about Purescript:
*edit: Meant to say React instead of flux