At Floobits, we started out using Backbone and handlebars because that is what we knew. About a year ago, we did a rewrite into React + Flux (our own implementation, because it was a year ago). The rewrite reduced KLOCs by something like 40%. Moreover, it radically simplified the code base. The big wins include one way data binding, updating views reactively, and removing boilerplate.
I did not realize it at the time, but two way data binding is evil. We spent a disproportionately large amount of time tracing (hard) bugs related to dispatching events. Bugs related to a child updating its parent that may or may not update the child again. Data should flow in one and only one direction. It may be possible to do this in Backbone, but its not encouraged when listening to models.
With any View system for the front end, you are necessarily responsible for creating the initial state of the DOM. You are also typically responsible for updating the DOM with your application state. If you ever run into a performance bottleneck, you will be forced to step out of your template system - you will either have to decompose your templates into needlessly small atomic chunks or resort to ad hoc DOM munging. Either solution is awful. React more or less lets you specify how to turn data in DOM in exactly one place for all time. In other words, if you care about performance, you will end up poorly reimplementing one of the best features of React.
And finally, Backbone has to be the most verbose JS framework I've ever used.
I did not realize it at the time, but two way data binding is evil. We spent a disproportionately large amount of time tracing (hard) bugs related to dispatching events. Bugs related to a child updating its parent that may or may not update the child again. Data should flow in one and only one direction. It may be possible to do this in Backbone, but its not encouraged when listening to models.
With any View system for the front end, you are necessarily responsible for creating the initial state of the DOM. You are also typically responsible for updating the DOM with your application state. If you ever run into a performance bottleneck, you will be forced to step out of your template system - you will either have to decompose your templates into needlessly small atomic chunks or resort to ad hoc DOM munging. Either solution is awful. React more or less lets you specify how to turn data in DOM in exactly one place for all time. In other words, if you care about performance, you will end up poorly reimplementing one of the best features of React.
And finally, Backbone has to be the most verbose JS framework I've ever used.