4 ms·

Sad about this. I think we still need a high performance way to observe changes on objects without a lot of framework bloat.

andrewmcwatters 11y ago
God forbid people use things like mutators and accessors or fire events.
- taylorbuley 11y ago
  JavaScript is all over eventing. But such a system requires cooperation or control between those firing and those subscribing to events. When the object we're talking about is e.g. an HTMLIFrameElement and it changes its own height it would be neat to be able to peek into object attribute changes.
  - andrewmcwatters 11y ago
    No, JavaScript is a language embedded in browsers. Web specifications detailing standard events are all over eventing, because browsers use event loops. On a related matter, Node does, too. JavaScript does not require an event loop. Any misunderstandings within this system are a misunderstanding regarding DOM events. HTMLIFrameElements don't change on their own. If they change based on the window resizing, you listen to the "resize" event, etc.
    - bzbarsky 11y ago
      > JavaScript does not require an event loop. It actually does now that Promise got added to the language. For extra fun the interaction of the JavaScript event loop and the HTML/DOM event loop is not actually specified and getting it specified will be rather exciting: both sides want to "own" the event loop...
      - _ZeD_ 11y ago
        just to add spice: there is also the CSS loop (with events like hovering and animations and stuff...) that is interesting to handle
        bzbarsky 11y ago
        Hovering is handled via the HTML/DOM event loop, since it needs to be coordinated with mouseover events. Animations, though, do need to be worked into this somehow. And they need to be able to run on a completely independent event loop to some extent so you can do animations on the compositor thread, not the DOM thread.
      - andrewmcwatters 11y ago
        I wonder how that works in practice outside of web environments, considering the spec doc doesn't mention it anywhere. I get the premise of having Promises in the language requiring an event loop, but without one, you'd be creating objects that never get resolved across frames (since they don't exist), which is still entirely possible.
        bzbarsky 11y ago
        The spec doc sort of mentions it: http://www.ecma-international.org/ecma-262/6.0/#sec-jobs-and-job-queues http://www.ecma-international.org/ecma-262/6.0/#sec-jobs-and... and when you initially start up your environment you do http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascript-initialization http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascri... which ends with a NextJob call. So you have to go do a Job. There are various sorts of Jobs, but all of them end their processing steps with a NextJob call. I guess the only issue is that what happens if you have unresolved promises when your Job queues go empty is implementation-defined, because an implementation is allowed to terminate when there are no Jobs. But if it doesn't terminate, resolving the Promise will enqueue a PromiseReactionJob. And I guess not actually call NextJob; that part is up to the implementation.
lyschoening 11y ago
There's still Proxy for that. https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...
- toomim 11y ago
  Indeed, Proxy always seemed like the more general version of Object.observe. It not only "tells you when state changes", but lets you write code to say what that means. What's the state of Proxy? Are the people behind it still working on it? Are we going to be able to use it? Will it be fast?
  - thomasfoster96 11y ago
    Proxy has already been standardised (in ES6) so it should be coming into browsers soon. It's a little harder to polyfill than O.o though.
    - AnkhMorporkian 11y ago
      As far as I know Proxy is impossible to polyfill. There are some patches which make old browser versions of Proxy meet the spec, but I just don't think you can close the Proxy gap with pure javascript.
      - pipeep 11y ago
        It's possible if you also translate all of the code that uses the polyfilled object by converting every MemberExpression to a function call, but that's probably a nightmare for performance.
        bcherny 11y ago
        what happens when i add a property to the object that i'm proxying after the Proxy is already instantiated? you wouldn't be able to detect the addition and add getters/setters for the property unless you use some sort of O.o or dirty checking on the underlying object. see https://github.com/bcherny/auditable https://github.com/bcherny/auditable for an implementation, sans O.o.

andrewmcwatters 11y ago

God forbid people use things like mutators and accessors or fire events.

taylorbuley 11y ago
JavaScript is all over eventing. But such a system requires cooperation or control between those firing and those subscribing to events. When the object we're talking about is e.g. an HTMLIFrameElement and it changes its own height it would be neat to be able to peek into object attribute changes.
- andrewmcwatters 11y ago
  No, JavaScript is a language embedded in browsers. Web specifications detailing standard events are all over eventing, because browsers use event loops. On a related matter, Node does, too. JavaScript does not require an event loop. Any misunderstandings within this system are a misunderstanding regarding DOM events. HTMLIFrameElements don't change on their own. If they change based on the window resizing, you listen to the "resize" event, etc.
  - bzbarsky 11y ago
    > JavaScript does not require an event loop. It actually does now that Promise got added to the language. For extra fun the interaction of the JavaScript event loop and the HTML/DOM event loop is not actually specified and getting it specified will be rather exciting: both sides want to "own" the event loop...
    - _ZeD_ 11y ago
      just to add spice: there is also the CSS loop (with events like hovering and animations and stuff...) that is interesting to handle
      - bzbarsky 11y ago
        Hovering is handled via the HTML/DOM event loop, since it needs to be coordinated with mouseover events. Animations, though, do need to be worked into this somehow. And they need to be able to run on a completely independent event loop to some extent so you can do animations on the compositor thread, not the DOM thread.
    - andrewmcwatters 11y ago
      I wonder how that works in practice outside of web environments, considering the spec doc doesn't mention it anywhere. I get the premise of having Promises in the language requiring an event loop, but without one, you'd be creating objects that never get resolved across frames (since they don't exist), which is still entirely possible.
      - bzbarsky 11y ago
        The spec doc sort of mentions it: http://www.ecma-international.org/ecma-262/6.0/#sec-jobs-and-job-queues http://www.ecma-international.org/ecma-262/6.0/#sec-jobs-and... and when you initially start up your environment you do http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascript-initialization http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascri... which ends with a NextJob call. So you have to go do a Job. There are various sorts of Jobs, but all of them end their processing steps with a NextJob call. I guess the only issue is that what happens if you have unresolved promises when your Job queues go empty is implementation-defined, because an implementation is allowed to terminate when there are no Jobs. But if it doesn't terminate, resolving the Promise will enqueue a PromiseReactionJob. And I guess not actually call NextJob; that part is up to the implementation.

lyschoening 11y ago

There's still Proxy for that. https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...

toomim 11y ago
Indeed, Proxy always seemed like the more general version of Object.observe. It not only "tells you when state changes", but lets you write code to say what that means. What's the state of Proxy? Are the people behind it still working on it? Are we going to be able to use it? Will it be fast?
- thomasfoster96 11y ago
  Proxy has already been standardised (in ES6) so it should be coming into browsers soon. It's a little harder to polyfill than O.o though.
  - AnkhMorporkian 11y ago
    As far as I know Proxy is impossible to polyfill. There are some patches which make old browser versions of Proxy meet the spec, but I just don't think you can close the Proxy gap with pure javascript.
    - pipeep 11y ago
      It's possible if you also translate all of the code that uses the polyfilled object by converting every MemberExpression to a function call, but that's probably a nightmare for performance.
      - bcherny 11y ago
        what happens when i add a property to the object that i'm proxying after the Proxy is already instantiated? you wouldn't be able to detect the addition and add getters/setters for the property unless you use some sort of O.o or dirty checking on the underlying object. see https://github.com/bcherny/auditable https://github.com/bcherny/auditable for an implementation, sans O.o.