Intent to Un-ship: Object.observe | Hacker News Reader

Intent to Un-ship: Object.observe

groups.google.com

19 pointsfrutiger10 comments

https://news.ycombinator.com/item?id=10494512

It's a done deal at this point but I think this is a mistake. Observables would have interesting uses other than in bindable UIs, such as making database interfaces where fields are bound directly to objects.

I think the thinking has become that while there are many great libraries out there that do some sort of observing changes in an object, it isn't general enough to be a language feature. There was a lot of disagreement on what the observable system should look like and how it should operate. For instance, some of the data-binding frameworks though the proposed spec for Object.observe was too heavyweight as they often don't need every change on an object.

At least for the time being it seems like this sort of thing is still better handled by library choice.

Personally, I felt like Object.observe should have used something more like RxJS Observables than events, and that a base class similar to the RxJS Observable would be great to generally add to the language alongside Iterable and Promise.

Have you seen the Observables proposal? It's Stage 1 but seems to be moving forward nicely, and it's more-or-less what I think you're looking for.

https://github.com/zenparsing/es-observable

I have seen that and IMHO I think it is something that ES should adopt. Just as Promises can solve the callback mess I think Observables can do a lot to solve the event mess, and given how deeply important events and event processing is to ES (hi DOM, hi EventEmitter), I think that could be huge. (In the meantime RxJS is great and moving at a good pace, but deeper language support would encourage other people to explore it beyond the already converted cultists like myself.)

Can observables be implemented efficiency without VM support? I can't think of a good way to do it without constant deep comparisons -- effectively "busy waiting" on changes.

Several of the libraries out there (including maybe the polymer "polyfill" for Object.observe, observe-js, although I haven't actually checked) use the ES5 tool Object.defineProperty to convert the members on an object to have observable semantics. There is also the new ES6/ES2015 Proxy class that can be used effectively and efficiently for the sort of meta-programming of wiring up an entire object for observation.

That said, there's also the tried and true methods of doing things "manually" a property at a time. Knockout and its observable functions remains rather efficient with a very long tail of older browser support.

> Observables would have interesting uses

Observables are still a thing; this is about Object.observe, a completely different thing.

> making database interfaces where fields are bound directly to objects

Proxies are also still a thing, and offhand I would think they'd be a lot more useful for something like that; that's practically what they were designed for.

What specifically about the Object.observe proposal did you actually like?

I didn't know about proxy... that looks interesting. Looks like it might obviate the need for Object.observe so maybe I take that back.

I would love to see more unused features removed from JavaScript. This would keep the language lean in the long term. Especially with the latest EcmaScript proposals, as excited as I am about them, I feel the language might become bloated one day.

Reply on news.ycombinator.com