与竞争对手相比，我很自然地被 Ember 出色的 API/设计/语法所吸引，但看到性能明显更差，我感到非常难过。 (例如，请参阅现在广为人知的 http://jsfiddle.net/samdelagarza/ntMdB/167/。)我的眼睛告诉我至少比 Chrome 中的 Backbone 慢 4 倍。
EmberJS 的 0.9.6 版本显然有许多性能修复，特别是在绑定(bind)和渲染方面。然而，当使用这个版本的 Ember 时，上述基准测试仍然表现不佳。
我认为上述基准可以说明一个框架的绑定(bind)成本。我来自 Flex，在 Flex 中，绑定(bind)的性能足够好，您不必经常考虑您要使用的每个渲染器的这 5 个绑定(bind)(可能乘以 20 个渲染器)是否会产生太多开销。易用性很好，但前提是要保持足够好的性能。 (更是如此，因为 HTML5 也经常针对移动设备)。
就目前而言，我倾向于认为与一些竞争对手相比，Ember 的美丽不值得牺牲性能，因为我们在这里谈论的是具有许多绑定(bind)的大型应用程序，否则您不需要这样的框架第一名。我可以忍受 Ember 的表现稍微差一点；毕竟它带来了更多。
所以我的问题是相当笼统和开放的:
- 基准测试的 Ember 部分是否写得足够好以显示 一个真正的问题？
- 0.9.6 性能更新是否可能非常低 key ？
- 主要负责人是否发现了表现不佳的领域？ 贡献者？
最佳答案
这实际上不是绑定(bind)速度慢的问题，而是执行了不必要的更多 DOM 更新。我们一直在对这个特定问题进行一些调查，并且我们对如何将这些多个操作合并为一个有一些想法，所以我确实希望这在未来有所改进。
也就是说，我看不出这是一个现实的基准。我绝不会推荐在 Ember 中(或使用 Backbone，就此而言)做大量的动画。在标准应用程序开发中，您永远不必以该频率同时更新那么多不同的 View 。
如果您能指出普通应用中的缓慢区域，我们将非常乐意进行调查。性能是我们非常关心的问题，如果在正常操作期间真的很慢，我们会认为这是一个错误。但是，就像我说的那样，高性能绑定(bind)驱动的动画不是我们的目标之一，我也不知道有谁会这样做。 Ember 通常与其他库配合得很好，因此应该可以插入一个动画库来在 Ember 之外制作动画。
关于performance - Ember 0.9.6 性能更新 - 重要吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10055579/