3

与竞争对手相比，我很自然地被 Ember 出色的 API/设计/语法所吸引，但看到性能明显更差感到非常难过。（例如，参见现在众所周知的http://jsfiddle.net/samdelagarza/ntMdB/167/。）我的眼睛告诉我至少比 Chrome 中的 Backbone 慢 4 倍。

EmberJS 0.9.6 版显然有许多性能修复，特别是在绑定和渲染方面。然而，在使用此版本的 Ember 时，上述基准测试仍然表现不佳。

我认为上述基准证明了一个框架的绑定成本。我来自 Flex，绑定执行得足够好，您不必不断地考虑您想要使用的每个渲染器的这 5 个绑定（乘以可能 20 个渲染器）是否不会造成太大的开销。易用性很好，但前提是保持足够好的性能。（更是如此，因为 HTML5 也经常针对移动设备）。

就目前而言，我倾向于认为 Ember 的美与它的一些竞争对手相比不值得性能损失，因为我们在这里谈论的是具有许多绑定的大型应用程序，否则你一开始就不需要这样的框架. 我可以忍受 Ember 的表现稍差一些。毕竟它带来了更多的东西。

所以我的问题相当笼统和开放：

  • 基准测试的 Ember 部分是否写得足够好，以显示真正的问题？
  • 0.9.6 的性能更新可能非常低调吗？
  • 主要贡献者是否确定了表现不佳的领域？
4

1 回答 1

7

这实际上并不是绑定变慢的问题，而是进行了不必要的 DOM 更新。我们一直在对这个特定问题进行一些调查，并且我们对如何将这些多个操作合并为一个有一些想法，所以我确实希望这在未来会有所改善。

也就是说，我看不出这是一个现实的基准。我永远不会推荐在 Ember 中（或使用 Backbone，就此而言）制作重动画。在标准应用程序开发中，您永远不必以该频率同时更新那么多不同的视图。

如果您能指出普通应用程序中的慢速区域，我们将非常乐意进行调查。性能是我们非常关心的问题，如果在正常运行期间事情真的很慢，我们会认为这是一个错误。但是，就像我说的那样，高性能绑定驱动的动画不是我们的目标之一，我也不知道它是为谁服务的。Ember 通常与其他库配合得很好，因此应该可以插入动画库以在 Ember 之外执行动画。

于 2012-04-07T21:46:01.193 回答