W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

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

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Wed, 20 Aug 2014 16:14:49 -0400
Message-ID: <53F501B9.6050402@mit.edu>
To: Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 8/20/14, 4:02 PM, Domenic Denicola wrote:
> 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.

I think that depends on your definition of "overhead", no?  I seriously 
doubt it's a single instruction, for example.

I do think it should be possible to keep this down to the cost of a 
hashtable lookup or something.  Not tiny, but OK if you don't have to do 
too many of them.

> 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.

eval (or in general entering JS code) is itself somewhat non-negligible. 
  Order of low hundreds of nanoseconds on modern desktop hardware in 
most browsers last I measured.  Browsers are trying to improve it, of 

>> 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.

The thing is, lazy computation is a implementation detail.  There are 
things that are lazily computed in some UAs but not others.

> 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?

Sure.  But it's not necessarily a fair assumption that the code adding a 
node to the DOM tree should consult the current values of all the 
various properties whose value might now be that node.

I do agree we should make things observable judiciously, in case that 
wasn't clear.  I just think we should consider performance and 
complexity implications during said judgments.

>> 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.

This is _probably_ true, yes.  Event dispatch, due to capture/bubbling 
and various other legacy bits has a ton of machinery that I'd hope 
Object.observe wouldn't involve.

> 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.

Agreed on that.  For that use case, I think Object.observe should be 
just fine.

Received on Wednesday, 20 August 2014 20:15:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC