Object.observe为何要被移除？

[luokuning]

前些天看有人讨论说 Object.observe (后面简称 O.o ) 将会从当前提案中移除，甚是震惊，为何大家一致叫好的特性会被废弃？要知道 O.o 之前已经到了 es7 的 stage-2，突然要被移除有点不解。经过了一番搜索，在一个帖子上找到了下面这段信息 (不逐字翻译，加入个人理解)：

三年前，Rafael Weinstein, Erik Arvidsson和我着手设计并实现我们认为是 MDV ("model-driven views")本质上要有的数据绑定系统。最初我们在 V8 的分支上实现了一个原型，然后获得了 V8 团队的同意从而打造了一个真实的上线版本( a real version upstream )，同时也在努力把 O.o 推为 ES7 的标准，以及和 Polymer 团队合作把他们的数据绑定 ( data-binding ) 系统构建在 O.o 之上。

三年后，风云际变。一些其他的数据绑定框架 (比如 Ember 和 Angular)也表示过对 O.o 的兴趣，但是很难看到它们能再改进现有的模型并整合 O.o。Polymer 1.0 完全重写了之前的代码，不过这次重写的版本却并没有使用 O.o。React 处理数据模型的方式更是尽量避免数据状态可变的特性，并且这种方式在 web 开发里变得相当流行了。

经过与组织的多次讨论之后(译者注：这里好像把原作者翻译成党员了 - -)，我计划从 TC39 (译者注：TC39 是ECMAScript 标准委员会，负责 ECMAScript 的规范制定) 撤销对 Object.observe (目前正在stage 2) 的提案，并希望年末能从 V8 中移除对其的支持 (根据 chromestatus.com 的数据显示，这个特性在页面上的使用率为0.0169%)。

对于出于实验性质使用了 O.o 并且因为被坑而在寻找一个替代品 (transition path) 的开发者们，可以考虑使用polyfill，比如 MaxArt2501/object-observe ，或者使用一个包装过的库，如 polymer/observe-js

另外也有一篇文章解释了 O.o 要被移除提案的原因，里面就引用了这段话的部分内容。文章还说到Angular 2团队曾经实验性的使用了 O.o，但是因为性能原因最终放弃了。原因在于 O.o 的使用限制了很多 V8 中已有的优化，导致被 observed 的对象会比 non-observed 的对象慢得多。过多的上下文切换 (框架和浏览器之间) 会对异步的数据变化通知造成挑战，也很难对框架进行大幅性能优化 (macro-optimizations)。Polymer 团队的头也说用了 O.o 调试很诡异。

总之基于种种原因，原生的 O.o 算是没戏了，已经在项目里用了或者想用这个特性的小伙伴可以找一些库支持，但是正如 O.o 作者说的，immutable.js 会是一个非常不错的选择！:stuck_out_tongue:

2016/4/26 更新: 测试在 Chrome 50 下这个特性已经被移除了。

[Vincent2015]

track

[yisibl]

好文！

[CreateSun]

哇原来是这样，今天学习的时候想试一下来着，还在纳闷为什么报错“ is not a function”，原来是这样，受教了！