4 ms·

Intent to Un-ship: Object.observe

19 points by frutiger 11y ago

api 11y ago
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.
- Lazare 11y ago
  > 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?
  - api 11y ago
    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.
- WorldMaker 11y ago
  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.
  - Lazare 11y ago
    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 https://github.com/zenparsing/es-observable
    - WorldMaker 11y ago
      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.)
  - api 11y ago
    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.
    - WorldMaker 11y ago
      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.
dang 11y ago
https://news.ycombinator.com/item?id=10494512 https://news.ycombinator.com/item?id=10494512
Jean-Philipe 11y ago
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.

19 points by frutiger 11y ago

api 11y ago

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.

Lazare 11y ago
> 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?
- api 11y ago
  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.
WorldMaker 11y ago
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.
- Lazare 11y ago
  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 https://github.com/zenparsing/es-observable
  - WorldMaker 11y ago
    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.)
- api 11y ago
  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.
  - WorldMaker 11y ago
    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.

dang 11y ago

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

Jean-Philipe 11y ago

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.