For the same reason I switched to Ember.js. I prefer the more opinionated way, the conventions. It looks to me, this repo try to provide some structure, but this is only one from the other 25 projects which do the same. The development effort is so fragmented. Should focus only one good react based framework. Luckily Ember.js is already implemented the good parts from React and from the Flux concept, stable, production ready, huge community. When you work with Ember, you dont feel that "fatigue" bullshit, because it is just disappeared. ;)

How is performance like on Ember.js? Because that's one of the reasons I'm switching from Angular. In React I think I have better and easier control of performance, because I mostly know what's going on.

Yes, you right, if you need only a simple component, React is almost the fastest.

However, if you have a couple of level deep nested structure, nested components, React perform very badly. Probably Ember.js will never be the fastest framework on todo list performance test. However in complex application, it is fast, or maybe faster than any other solution. The Glimmer Engine 2 is on the way, will be released in a couple of weeks with backward compatibility. So if you built an Ember.js app before, it will enjoy this performance boost as well. And improving performance will never stop, so it is just getting better, meanwhile the developer happiness is on the top, thanks to Ember ecosystem, the add-ons, the Ember-CLI, etc...

In most of the projects the importance of the speed of rendering a tiny component is insignificant comparing to the speed of the network, or to the importance of the management of model/serialisers/adapters, or to dealing with app router/services, or to the importance of testing and deployment.

Ember.js project's main goal is providing a complex solution, where the developer has to focus only to ship a product, building features and release it. Ember achieved this goal more than a year ago, the whole framework is matured, more production and corporate ready than any other solution out there at the moment.

A great presentation about how intercom.io can ship fast thanks for Ember.js: https://www.youtube.com/watch?v=fVwDuMGVhYY&sns=tw

Nice comparison of renderers: https://auth0.com/blog/2015/11/20/face-off-virtual-dom-vs-in...

I'm looking into switching to Ember... The simple React stuff I've made its fun but it looks like too much trouble for big stuff. Also Ember is getting server side rendering.

Yep, great choice. I've just updated my free Ember.js tutorial, if you would like to learn more about it: http://yoember.com

I'm playing with the server side rendering nowadays, and it is promising. It will be easy to use and nicely integrated with the whole ecosystem.

This blog post is not short, but you can get a view, what is the core team's plan for the next couple of weeks, and how the framework evolve further this year. http://emberjs.com/blog/2016/01/23/core-team-face-to-face-ja...

I think anything recommended by Dan Abramov is safe to use. I'm not a fan of the popular react/redux boilerplates because most of them are very opinionated. Many boilerplate authors will actually invent new conventions within the boilerplate (e.g. use my new framework to do API calls). Yet their code is left uncommented and they assume you will just believe that their conventions are actually beneficial to follow. You're better off just starting from scratch.

I was once down-voted heavily on HN for saying the React ecosystem seems immature (this was about a year ago). A year later, it still seems like there's no consensus on how to build scalable apps with react.

The names are all so similar. Incredibly frustrating.

What did you end up using?

I don't want to proselytize. Every choice is a trade-off. And project needs sometimes dictate technological decisions. But this post touches on many of the reasons I've landed on Ember: https://medium.com/@jonpitch/ember-get-shit-done-36383c2ccc5...