RE: Object.observe()able properties on the web platform

From: Boris Zbarsky <bzbarsky@mit.edu>

> The overhead of checking whether something observes the object might be quite non-negligible in itself. 

I can't really speak to this personally. I've been told, or at least marketed-to, that it is not an overhead for normal JS objects. To Olli's point, I would hope that since DOM objects are eventually exposed as JS objects, that can prove true for them, if nothing else by eval'ing the relevant JS code.

> Especially so for cases where the property value is computed lazily, because then you need some sort of extra something to notice when the value might have changed, which you don't need without Object.observe.

That's fair, but I would assume we would not make such properties observable.

> You just assumed you have the old and new value.

Yes. Is it not a fair assumption that the code setting a new value for, say, wake-lock, can consult the current value of the wake-lock?

> You also constructed an object.  And defined properties on it.  I can assure you that doing that is non-negligible in performance terms.

I would hope that the overhead of using ES's built-in "event" mechanism is lower than that of using EventTarget.

> It's not entirely, because the bindings layer has no idea when property values change, except for the obvious case of writable properties that can't change out-of-band.

You are right; I was thinking of this wrong.

---

Again, for all of this, I want to emphasize that what I'm interested in is supplanting { prop, propchanged } EventTarget subclasses in favor of { prop } classes. I have a hard time understanding why Object.observe() will be slower or more difficult to implement than the propchanged-event solutions we are currently using. Perhaps it is simply an issue of the DOM and JS worlds not talking to each other well within existing implementations, but each vendor shipping promises has already figured this out: Blink + V8 with their ScriptPromise bridge into the V8 API, and Gecko + SpiderMonkey by implementing promises in Gecko instead of in SpiderMonkey.

Received on Wednesday, 20 August 2014 20:03:05 UTC