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

Devs probably don't care if these things are fired sync, as long as when
they do fire, they fire once and the value/changes aren't stale. Honestly,
ready/created, inserted, and removed wouldn't be an issue if they map to
micro tasks, right? (as long as the final callback is not stale). 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.

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)


Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Mon, Mar 11, 2013 at 11:55 AM, Daniel Buchner <daniel@mozilla.com> wrote:

> Ready/created, inserted, removed, and attributeChanged are the minimum
> must-havs for developers - we heavily rely on each one of these callbacks
> in the components we've developed thus far. The usefulness of this API is
> neutered without these hooks - they're table stakes, plain and simple.
> Jonas, how are non-bubbling callbacks so crushing? Are we honestly
> designing for the dev who decides to ignore all the best practices,
> tutorials, evangelist demos, etc and run a crushing loop every time an
> attribute value changes despite the obvious idiocy of their actions? This
> is not an API that will be widely used by every Bobby Tables and Samantha
> Script Kitty on the block - let's not design API features and 99%-case
> ergonomics for a phantom developer persona that is a fringe-at-best factor.
>
>
> On Fri, Mar 8, 2013 at 10:49 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Mar 6, 2013 2:07 PM, "Dimitri Glazkov" <dglazkov@google.com> wrote:
>> >
>> > Here are all the callbacks that we could think of:
>> >
>> > * readyCallback (artist formerly known as "create") -- called when the
>> > element is instantiated with generated constructor, createElement/NS
>> > or shortly after it was instantiated and placed in a tree during
>> > parser tree construction
>> >
>> > * attributeChangedCallback -- synchronously called when an attribute
>> > of an element is added, removed, or modified
>>
>> 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 :-)
>>
>> / Jonas
>>
>
>