Re: Shadow DOM: state of the distribution API

I'm wondering how we should estimate the performance impact of these
proposals.

In the era of Web Components, I expect that one page has 1k Web Components.
The page must work without any significant noticeable performance
regression, compared to a page which doesn't use Web Components. That's our
bottom line.

In the current distribution model, I expect we can achieve this goal,
thanks to the lazy evaluation of distribution.

Is there any plan how we should evaluate these proposals in terms of
performance primitives?


On Thu, May 7, 2015 at 7:53 AM Ryosuke Niwa <rniwa@apple.com> wrote:

>
> > On May 6, 2015, at 2:39 PM, Elliott Sprehn <esprehn@chromium.org> wrote:
> >
> > The 3 proposal is what the houdini effort is already researching for
> custom style/layout/paint. I don't think it's acceptable to make all usage
> of Shadow DOM break when used with libraries that read layout information
> today, ie. offsetTop must work. I also don't think it's acceptable to
> introduce new synchronous hooks and promote n^2 churn in the distribution.
>
> Sorry, I don't follow. If we're making offsetTop to synchronously return
> the correct value, then authors can easily write code that performs in
> Ω(n^2) by obtaining the value of offsetTop between adding/removing direct
> children of a shadow host.  On the other hand, if we're trying to prevent
> O(n^2) behavior, then we should be adding API to asynchronously retrieve
> layout information.
>
> - R. Niwa
>
>
>