Ember 0.9.6 Update - Significantly?
I was naturally attracted to Ember's good API / design / syntax compared to the competition, but was very saddened to see that performance was significantly worse. (For example, see the well-known http://jsfiddle.net/samdelagarza/ntMdB/167/ .) My eyes tell me at least 4x slower than Backbone in Chrome.
Version 0.9.6 of EmberJS appears to have many performance fixes, particularly around bindings and rendering. However, the above test still doesn't perform well when using this version of Ember.
I see the above criterion as a demonstration of the cost of binding one structure. I come from Flex, where the bindings do well enough that you don't have to constantly wonder if those 5 bindings for each renderer (multiplied by 20 renderers) won't be too overhead. Ease of use is good, but only if good enough performance is maintained. (Especially since HTML5 is also often targeted at mobile phones.)
Be that as it may, I tend to think that the beauty of Ember is not worth a performance hit compared to some of its competitors, since we're talking about large applications with many connections here, otherwise you won't need such a structure in the first place. I could live with Amber playing a little less well; after all, it brings more to the table.
So my questions are pretty general and open-ended:
- Is Ember part of a well written test that shows the real question?
- Perhaps updates 0.9.6 could be a very low key?
- Are areas of poor performance identified by major contributors?
source to share
This is not really a problem of slow bindings, but doing more DOM updates than necessary. We are doing some research on this particular issue and we have some ideas on how to combine these multiple operations into one, so I expect this to improve in the future.
However, I don't see this as a realistic benchmark. I would never recommend doing heavy animation in Ember (or with Backbone for that matter). In standard application development, you never have to update many different views at the same time at this frequency.
If you can specify slow areas in a regular application, we'd be very happy to investigate. Performance is a big concern for us, and if things get really slow during normal operation, we'll look into this bug. But as I said, performance animation related to snapping is not one of our goals, and I don't know anyone who it is for. Ember usually works well with other libraries, so you can include an animation library for animations outside of Ember.
source to share