I'm disappointed to see this prioritized over, say, a focus on reduced library size or simply getting to a stable 1.0 release. I'm not sure how this moves React forward, though I'm sure it's a "nice to have" for some people.
Still, perhaps we'll learn more about the roadmap and goals of the team at the React conference this week.
1.0 implies API stability, so now is exactly the time they should be prioritising things that potentially change the API going forwards.
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.
Our experience with Backbone, was that the majority of code in your models and views is about keeping the two in sync. i.e. if a field on a model changes, how to update the element that the view controls in the most efficient possible way. We experimented with several methods of handling data-binding (two-way at the time) for us, but weren't satisfied with any of them.
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.
This repeats my experience too. Backbone gets nasty too soon: nested entities, pagination, invalidation, caching have to be ad-hoc ugly solutions because Backbone is just too rigid where it better be flexible, and too flexible where it should have been rigid.
We gradually moved from Backbone to React+Backbone, and finally to React+Flux. It's been amazing since.
The point of this is exactly to reduce the library size AND getting to a stable 1.0 release. By making the class system optional, it becomes an optional dependency which reduces the library size. Supporting only createClass in a stable 1.0 release would mean that we're stuck with that dependency.
The way we see it, ES6 and 7 are around the corner and then the createClass dependency becomes optional.
Are we still arguing about file-size size? Gzip? Its smaller than a medium-to-small .jpeg image, and connections are only getting faster. No need to loose sleep over mere perceptions!
The stuff announced is good/relevant b/c it signals some important decisions and allows other parties to weigh in in time for any major shifts to be made before 1.0.
Still, perhaps we'll learn more about the roadmap and goals of the team at the React conference this week.