与竞争对手相比，我很自然地被Ember的API /设计/语法所吸引，但看到性能明显变差，我感到非常难过。 （例如，请参阅现在众所周知的http://jsfiddle.net/samdelagarza/ntMdB/167/。）我的眼睛告诉我至少比Chrome中的Backbone慢4倍。
EmberJS的0.9.6版本显然有许多性能修复，特别是在绑定和渲染方面。但是，使用此版本的Ember时，上述基准测试仍然表现不佳。
我将上述基准视为一个框架绑定成本的示范。我来自Flex，绑定表现得非常好，你不必经常考虑你想要使用的每个渲染器（乘以20个渲染器）的这5个绑定是不会有太大的开销。易用性很好，但只有保持足够好的性能。 （更重要的是，因为HTML5也常常以移动设备为目标）。
就目前而言，我倾向于认为Ember的美丽与其竞争对手相比并不值得表现，因为我们在谈论有很多绑定的大型应用程序，否则你不需要这样的框架第一名。我可以忍受Ember的表现稍差;毕竟它带来了更多的东西。
所以我的问题相当笼统和开放：
答案 0 :(得分：7)
这实际上并不是绑定速度慢的问题，而是进行了比必要更多的DOM更新。我们一直在对这个特定问题进行一些调查，我们对如何将这些多个操作合并为一个有一些想法，所以我希望将来能够改进这个。
那就是说，我看不出这是一个现实的基准。我永远不会建议在Ember中使用重型动画（或者使用Backbone，就此而言）。在标准应用程序开发中，您不应该同时更新那么多不同的视图。
如果您可以指出普通应用中的慢速区域，我们将非常乐意进行调查。性能是我们非常关注的，如果在正常操作期间事情确实很慢，我们会考虑一个错误。但是，就像我说的那样，高性能的绑定驱动动画不是我们的目标之一，也不知道任何人是谁。 Ember通常可以很好地与其他库一起使用，因此应该可以插入一个动画库来在Ember之外进行动画制作。