Re: [whatwg/dom] Declarative Shadow DOM (#831)

> > Should the overhead we care about be against imperative DOM creation?
> 
> That is a separate issue.

Can you clarify what you mean by this being a separate issue? We may be talking past each other, since I believe this is **the primary issue**.

Put another way, what is the speed you're concerned about? I've been thinking about declarative shadow dom as:
 1. The cost of shadow DOM attachment, which is **identical between declarative and imperative SD**.
 2.  **-PLUS-** the "overhead" of creating the template document and moving contents around
 3.  **-MINUS-** the cost of firing up JS to interpret the code that contains `.attachShadow()` for imperative SD.

Number 3 is the reason DSD exists. Full stop. Either the overhead of JS, or just the *requirement* to run JS, is what developers are trying to avoid when they reach for DSD.

I'm happy to profile <span>#</span>2 above, if that's what concerns you about the proposed API. Though I will say, the alternative (as [discussed here in the explainer](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#timing-attach-the-shadow-on-opening-or-closing-template-tag)) is to attach the shadow root at the opening `<template shadowroot>` tag, and parse directly into that root. And that has been met with fairly strong negative reactions from some implementers, due to the complexity and bugginess of changing the parser in such a significant way. I don't entirely disagree with them on this point.

In my [experiments with DSD vs. imperative SD](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#performance), the net result of <span>#</span>2 minus <span>#</span>3 above was **positive**. I.e. the overhead you're concerned about is less than the pure savings from not running JS, no matter how that was done. Do you get different results?

> 
> Another issue is whether the proposal itself is using fast algorithms or can we do something better. It does seem to do somewhat redundant work by creating template and then later removing it and creating nodes in another document and then adopting them to another document almost immediately. (It is really puzzling to me why simple performance profiling can't be done. I'd do it myself if I knew something as simple as https://profiler.firefox.com/ for Chrome. If you haven't tried that profiler, try it, especially with Nightly if you're interested in browser internals.)

A few reminders about the explainer: it has a section [dedicated to performance](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#performance), and also a [section describing the Chromium perf test](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#shadow-dom-vs-light-dom-speed) that explicitly measures the overhead of shadow DOM vs. light DOM. 

In Chromium, profiling can be done via https://ui.perfetto.dev/. I haven't used https://profiler.firefox.com/, but from a quick glance, it seems quite similar.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/831#issuecomment-1215603768
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/831/1215603768@github.com>