First off, I wouldn’t say Ryan’s had vitriol (at least, none that I’ve seen and I’ve followed him on Twitter for some time). Furthermore, a lot of his concerns are very real. If I had to give my own list of complaints on Ember:
- JS heavy apps do not perform well on Android/Cordova Android (hoping the fix in chrome webview will improve this in a few months)
- It’s hard to build good nestable components like carousels, off-canvas, or modals without some serious work arounds. (1.10’s refactor mostly addresses this with block params).
- initial render time is horrendous. Fastboot and HTMLBars will (hopefully) fix this, but I suspect more could be done to address how slow Ember is to get going. Compare the refresh time of Ember to Angular and React in Ryan’s presentation.
- adding to, removing from, or reordering collections/lists is basically a no can do. (again HTMLBars is likely to fix this, especially once the react style diffing is involved). To be able to do this well, you’ll need to design and implement custom components for managing your lists. You don’t get performant list handling out of the box, and nearly every big data type or digest is a list.
- Bindings, CPs, Observers encourage a very broken data flow that quickly make things such as validation-inputs much trickier to implement well. I think the new explicit binding and streams are great things.
Ember.run family is passed by very quickly in explanations “it’s here but you’ll probably not need it”. In actuality,
Ember.run.schedule will save your app’s mobile performance. In my own case, I implemented two new queues in Addition to Ember’s own for handling background tasks and background data refreshing after afterRender concludes.
In short, Ember as an MVC framework is pretty awesome, but Ember for performance is not. Using Ember.run correctly, I think Ember does a far better job than Angular (I don’t know about React) at managing a JS heavy app without overloading the CPU, but as much ground it gains there it loses far more with it’s poor rendering performance. Rendering performance is definitely something Ember can fix, mostly because it’s been architected in a manner that improving parts doesn’t require a framework overhaul.
I’m not bailing on Ember after seeing React’s render performance put on full display. I think we’ll gain this ground back and then some with HTMLBars + React style diffing, and I think React’s code style disregards separation of concerns to a level that forces designers to be engineers.