[nebstrebor]

I've done sufficient with both Angular and React to have decided to go with React for next our project. Its a better fit for this particular project because the "reusable components" paradigm fits what we're doing, which includes building a non-model-specific framework that we can reuse for different models, where the framework renders slightly differently based on meta data provided with the model. We'll probably use Backbone for the model (& meta) & router. I like Angular, and would like to use it for a project that's more concrete and less meta.

[jholly]

Something about Angular rubs me the wrong way. I think it has to do with dirty checking. Either that or the scope magic that happens. React, comparatively, is quite straight forward. I hope it stays that way, a minimal API and no magic.

The more I look into react the more I wonder if some intermediary representation of the DOM ought to be standardized so that a native "diff/batch" algorithm can be provided as regular functions. I think react would help this cause if it can break up into several projects (react-events, react-virtual-dom, react-dom-diff/batch, etc). Perhaps other projects can adopt parts of react into their own frameworks. Just a thought.

[jordwalke]

Core team member here. That's excellent feedback and we are definitely going to be pushing in that direction where we can. API simplicity will always be a primary goal and a modular core implementation will help advancement of mobile support and testability. The event system is already self contained and shouldn't depend on anything in React at all.

[AdrianRossouw]

I had the same feeling as you. I became ok with it after I realized it could be removed in the future.

http://daemon.co.za/2014/03/why-wrong-to-be-afraid-angular

I am looking forward to trying react though, because of how well it plays with backbone (which is still my preference)