Re: [webcomponents] Per-type ready event for Custom Elements

Surely then we should remove all events defined by the Web Component specs
in favor of Promises, right? We're talking about a single event here - this
seems like a bit of an overreaction. Though Promises are cool, and I am not
against providing a complementary solution, you haven't presented anything
of significant, material relevance that should dissuade us from providing
backwards compatibility in the style of code developers are familiar with
and able to use today.

I believe providing for today and tomorrow with this API addition is a
sensible move for the following reasons:

- Doesn't force reliance on another emerging API
- Provides a hook to developers through an existing code path they are
familiar with
- Doesn't force developers to treat this one event as the odd-one-out by
requiring different handling
- Has a relatively low touch implementation path (as far as I have
estimated)

Your mention of tiny, incremental maintenance cost is inconsequential - the
entire Web Components family of APIs will require far more maintenance
(this is a red herring). The arguments "a small thing will need to be
maintained" and "let's use newer, unreleased stuff because it is better",
are not altogether convincing points (which is of course my opinion, I
welcome yours).


On Fri, Sep 27, 2013 at 8:02 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Fri, Sep 27, 2013 at 10:56 AM, Daniel Buchner <daniel@mozilla.com>
> wrote:
> > I don't see any compelling reason not to provide both.
>
> Twice the maintenance cost, more to learn, etc. Promises will be in
> implementations long before web components are stable anyway. I don't
> really think there's much of a point to be made here.
>
>
> --
> http://annevankesteren.nl/
>