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

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

- I thought the concern was over the same issues that plagued mutation
*events*, namely perf-crushing event bubbling sparked by frequent DOM
changes.


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?

- I wasn't aware of setting up such a strawman, I honestly thought the
issue was perf. I thought this because Jonas said this: "This will
have many of the same problems that mutation events had. I believe we
want to really stay away from synchronous. So yes, this looks
dangerous and crazy"

-----

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

Not sure what you mean here.

- I mean, that it doesn't matter if you make all the callbacks fire at
the end of a micro task, as long as you're not reporting old,
irrelevant changes to the developer - for instance: if an attribute
foo changes 3 times before the micro task is finished, the browser
should resolve the mutation record set to only fire one callback for
the last "fresh" occurrence of the mutation/action in question.

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

- Great, so what's the problem here? Are we officially in violent agreement? :)

-----

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

- these four basic callbacks/mutations are essential to custom
element/component development - they will be used frequently, in our
experience thus far.

-----

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

- The target and actual audience is probably not going to be
noobs/beginners, this is a pretty complex API - it appears you agree:
"the typical culprits for not caring are not apps".

- Daniel