[machty]

It might not be so much a genius vs non-genius thing so much as your particular app not needing the heavyweight app-state management that Ember provides.

It's worth pointing out that the Ember core team has been approached by the React core team with the intent of unifying React's view layer with Ember's application state management, which is a major component of what Ember offers relative to other frameworks. If you haven't had to solve major problems with navigation, routing, complex nested async logic, etc., for the particular app you're trying to build, then it sounds like React would get you most of the way there, but even the React team themselves realize that for medium-large scale apps, React's only going to take you so far.

[thatthatis]

Where did those discussions lead? "EmberJS merges with ReactJS" seems like a pretty exciting headline.

[machty]

Ember's approach to watching for changes is pretty different. Also, the Ember view layer refactor codenamed HTMLbars has yielded some extremely promising (though admittedly early/premature) performance improvements that often outperform the React equivalent. So we're open to the idea and we have much we can learn from each other but we're not going to merge in React if we can do a better job :)

[jessep]

For me, and I think most people who get excited about it, performance isn't what attracts me to React. It is the semantics (is that even the right word?). The nice way it lets me think about things.

It looks to me like htmlbars is handlebars emitting DOM rather than string. In that case, I think it will be missing the benefits of React. Again, though, I obviously don't understand Ember well.

[jessep]

Yeah, that's a good point. The things I've been building with both have been small and relatively simple.