Adam Klein has announced that he is withdrawing the Object.observe proposal from consideration at the next TC39 meeting.
In a post describing his thinking, Klein says that "the world has changed."
Over three years ago, Rafael Weinstein, Erik Arvidsson, and I set out to design and implement what we believed to be the primitive underlying the data-binding system of MDV ("model-driven views"). Three years later, the world has changed in a variety of ways. While other data-binding frameworks (such as Ember and Angular) showed interest, it was difficult to see how they could evolve their existing model to match that of [Object.observe].
In an interview, Klein told InfoQ that Object.observe "was an attempt to distill something essential about [various frameworks] into a low-level primitive that could be used by all of them. Yet it was hard to exactly match these varied programming models with the same underlying primitive."
The promise of Object.observe was straightforward, but the actual implementation turned out to be problematic. At one point, the Angular 2 team experimented with Object.observe for change detection, but that idea was abandoned after performance suffered. Igor Minar from the Angular team told InfoQ that its "runtime cost was not insignificant":
O.o() disabled many optimization paths in V8 which resulted in all observed objects to perform significantly slower than non-observed ones. The async delivery of change notification was challenging because it required a lot of context switching between the framework and the browser, making it hard for the framework to perform macro-optimizations.
Matt McNulty, lead on the Polymer team at Google, expressed similar reasons for moving away from Object.observe. Complex apps ended up "creating tens of thousands of O.o calls," he told InfoQ. "This was tricky to debug, and had strange performance characteristics. On Chrome, setup time was long but runtime was fast. On polyfilled browsers, the opposite was true."
As immutable data structures become more prevalent among JavaScript developers, the need to watch the mutation of objects becomes moot. Minar echoed this sentiment, saying the "rise in popularity of immutable data structures, functional programming, and unidirectional data flow, rendered O.o() less impactful that what was initially thought."
Per the TC39 standards process, proposals must gather "significant usage and external feedback" before they can move to stage 3. Object.observe is currently at stage 2. According to Klein, Object.observe is only used in "0.0169% of Chrome pageviews" and it is only supported in Chrome and Opera (both based on the Blink engine). The withdrawal of the proposal shows the standards process is working. McNulty said that "Out at the bleeding edge of the platform, we should be unafraid of innovation. Features being proposed, vetted, and sent back to the drawing board if they don’t catch on is the system working exactly as it should."
Klein told InfoQ he agrees:
The TC39 process is intended to be an incubator of ideas until they are merged into the full ECMAScript spec. The process is designed to gather additional feedback at each stage including, when necessary, the feedback that a proposal should no longer be considered for inclusion in the language. Withdrawing O.o from TC39 after careful consideration rather than deprecating the feature from the official language farther down the road should be considered a success of the process.
When Object.observe is removed from V8, it will force a breaking change in Node.js, which depends on the JavaScript engine. Mikeal Rogers, Community Manager for Node.js Foundation told InfoQ that those using the Long Term Support (LTS) version of Node.js don't need not worry:
It’ll be a breaking change in a future major release. It won't effect LTS because we don’t do major upgrades of V8 in LTS.
TC39 is the standards committee charged with standardizing the ECMAScript programming language.