Still, perhaps we'll learn more about the roadmap and goals of the team at the React conference this week.
Also, is 40kb gzipped really something to lose sleep over? Especially when the mere act of moving from old jQuery/Backbone soup to React reduces the size of my real code by a far greater amount.
It's my (perhaps flawed) understanding that React deals only with the "view" part of an app, and that you can use Backbone and React concurrently.
Could you elaborate on what you call "Backbone soup" and how React helps solve this problem?
I was building a particularly complicated content editor with Backbone, and was getting frustrated. So I spent the next morning learning React, then re-implemented the whole thing that afternoon. All the complexities I was grappling with disappeared. Obviously there were new challenges to replace the old ones, but we've found it's much easier for someone to pick up work on a React project than it ever was with Backbone.
To start with we were using Backbone models with React views, but now we just use a flux implementation (Fluxxor), and don't bother with much else. Our client-side JS stack is essentially React, Immutable, Fluxxor, superagent, moment and mousetrap, with only the first three being core ingredients.
We gradually moved from Backbone to React+Backbone, and finally to React+Flux. It's been amazing since.
The way we see it, ES6 and 7 are around the corner and then the createClass dependency becomes optional.