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
