W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

Re: Why can't we just use constructor instead of createdCallback?

From: Adam Klein <adamk@chromium.org>
Date: Tue, 18 Feb 2014 16:12:02 -0800
Message-ID: <CAEvLGc+vQ-tGB5X1xDiv1VBAGSmcn1Bw1qKNPmVuAwuEA51+8Q@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>, Ryosuke Niwa <rniwa@apple.com>, Erik Arvidsson <arv@chromium.org>, WebApps WG <public-webapps@w3.org>, "Edward O'Connor" <eoconnor@apple.com>, William Chen <wchen@mozilla.com>
On Tue, Feb 18, 2014 at 3:26 PM, Dimitri Glazkov <dglazkov@google.com> wrote:
> On Tue, Feb 18, 2014 at 2:59 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> > On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov <dglazkov@google.com> wrote:
> > > The thing that really bothers me is that this approach is contradicting
> > > itself. We go to into pretty elaborate lengths to enable running
> > > constructors during parsing, but the key performance lesson developers will
> > > immediately learn is to avoid constructors on custom elements, because they
> > > will trigger the two-phase code path during parsing. Here's a thing that you
> > > can use, but you probably don't want to ever use it.
> >
> > The above paragraph appears to assume that creating this list is slow.
> > Do you have data to back that up?
> No, of course not :) It's a first intuitive reaction.

One example that seems intuitively problematic about this approach (to
me, anyway) are those parts of the parser that inspect the tree during
parsing: foster parenting. I'm not sure it's a performance issue so
much as a complexity issue. Consider:


When following the spec
any text in that algorithm which says "parent node" need to be patched
to say something about this new list of to-be-attached nodes.

Patching all such references seems likely to be difficult and
error-prone, but I admit that I can't quantify those worries.

- Adam
Received on Wednesday, 19 February 2014 00:12:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:22 UTC