Re: [webcomponents]: What callbacks do custom elements need?

On 3/11/13 3:44 PM, Daniel Buchner wrote:
> Just to be clear, these are callbacks (right?), meaning synchronous
> executions on one specific node. That is a far cry from the old issues
> with mutation events and nightmarish bubbling scenarios.

Where does bubbling come in?

The issue with _synchronous_ (truly synchronous, as opposed to end of 
microtask or whatnot) callbacks is that they are required to fire in the 
middle of DOM mutation while the DOM is in an inconsistent state of some 
sort.  This has nothing to do with bubbling and everything to do with 
what happens when you append a node somewhere while it already has a 
parent and it has a removed callback that totally rearranges the DOM in 
the middle of your append.

> Come on folks,
> let's be pragmatic and honest, there are far worse events in use today,
> and the web is still alive and kicking: mousemove, mouseover, mouseout,
> resize, etc. Most/all of these kinds of existing, perf-intensive events
> bubble and are fired with far more frequency than attribute changes on a
> node - further, devs can always debounce the calls if they please.

"resize" firing frequency is throttled in browsers.

mousemove/over/out firing frequency is throttled in browsers.  For 
example, last I checked Chrome will only fire mousemove at about 60Hz.

But the issues with synchronous callbacks are not about performance, 
last I checked, so I'm not sure why you're setting up this strawman.  Or 
are people arguing something here based on performance considerations 
that I missed?

> Devs probably don't care if these things are fired sync,

Good, because they aren't.

> as long as when they do fire, they fire once and the value/changes aren't stale.

Not sure what you mean here.

> Honestly, ready/created, inserted, and removed wouldn't be an issue if
> they map to micro tasks, right?

Running script at end of microtask is generally fine by me, since it 
doesn't have the issues that running script sync does.

> If attribute change callbacks are your worry, Brian Kardell
> mentioned something sensible, give people a way to whitelist just the
> ones that they want to watch for - assuming that is faster than simply
> telling devs to use basic if/switch logic inside the callback.

It's almost certainly faster but may not be worth the machinery, 
depending on how much this is actually going to be used in practice.

> There are many options here, let's not have an API-degrading, whopper
> freakout over a nascent concern of a fringe perf issue that is, to a
> large extent, self-mitigating/healing. (devs generally don't want to
> have slow crappy apps - built-in incentives to not suck are usually the
> best kind)

You and I seem to have different opinions on whether people care about 
their code being a resource hog... Note that the typical culprits for 
not caring are not "apps", though.

-Boris

Received on Monday, 11 March 2013 20:16:44 UTC