Shadow DOM for child components

[nweldev]

In "real life", most projects are split into several components. With some frameworks/libraries (like lit-element), or even with VanillaJS, these components usually have a Shadow DOM attached, which could have an impact on rendering performance.

Regarding a possible "VanillaJS Web Components" implementation following common good practices (see #749 (comment)), using a Shadow DOM could also help to enhance rendering performances, as a custom element light dom shouldn't be modified before it's attached to the dom (see the HTML specs).

Yet, the tests seem only to allow a shadow dom for the main-element.

• Is it already possible to attach a shadow-dom to a "row" component, and if so, how?
• If not, where could I start to make this possible?

[ryansolid]

It isn't as far as I know there is no benefit to do so if it is possible. The problem is we are dealing with a table and TR which requires using a native extension to keep HTML structure. So there is no elements to stick in the shadow root. I mean maybe just a slot. It sort of doesn't make much sense. If you see a way of doing this in a way that does it probably is worth giving it a shot.

I've tested webcomponent libraries just never submitted them. The only one other than VanillaWC I believe is LitElement but that implementation is sort of unrealistic as it is all in one component with no row components and in no way shows the overhead.

When I implement Solid Element I found it to be about a 15% performance hit using row elements and the library is pretty performant(https://webcomponents.dev/blog/all-the-ways-to-make-a-web-component/). Vanilla WC is fairly optimal and about the best overhead we can hope. It only gets worse from there.

But you are correct that in a real app we'd use the shadow dom. It just isn't going to be equivalent to the other tests here if we do that. You can and should test that and maybe publish your results but it's hard to call the comparison fair in that sense.

The truth of the matter is webcomponent performance in a more realistic performance is going to be good chunk less performant. While this benchmark is synthetic and real React apps say aren't quite like this, their components more or less scale. I can't make the same claim of a lot of libraries here and Web Components are no different. Web Components with Shadow DOM even more so.

The articles of mine you might find the most relevant are actually these 2:
The Fastest Way to Render the DOM
The Real Cost of UI Components

And this one is a good classic too by @localvoid author of ivi:
How to win at Web Framework Benchmarks

[nweldev]

Thx for all these links @ryansolid, I'm always happy to learn 🙂

Web Components, especially with Shadow DOM, having a bad impact on performance is exactly my point here. Sorry if I wasn't clear enough.

I'm especially thinking about WC good practices (WhatWG, W3C, google, gold-standard). Those are generally followed but have an impact on performances. Therefore, I think giving an example that doesn't follow any of those is misleading.

If you don't use a Shadow DOM, you shouldn't set any content in the constructor either. So, if you follow good practices, using a Shadow DOM and templates to pre-parse the elements may (or not) lead to better performances than using innerHTML at connection time, for example. Without the possibility to use a Shadow DOM, we can't compare those.

I didn't read enough of the slower examples (React, Vue and Angular, for example) to really see what would be an honest comparison or not, thx for the correction. Of course, you're right about lit-element. A "real" example using a second component would lead to worse performance, which would be less misleading IMO. But only "by itself", not compared to the others, I guess.

[nweldev]

This issue should be reopened because there is still a lot of problems when using the shadow dom on row elements based on #764.

Especially:

• A tr element can't have a shadow dom, so this requires to use a wrapper (custom element or div), which is messing with the table > tbody > tr logic. We would need to rethink this project entirely, as the webdriver tests (and therefore all existing implementations) uses tr.
• Row styles aren't separated from the rest of the page, and bootstrap is used. We would need to rewrite all CSS for better results.

[nweldev]

Also, to answer #764 (comment):

Here are my results after #764 :

And after a revert of 9e4bee8 and running npm run bench keyed/vanillajs:

So I don't think this is related to #764. @krausest, how did you obtain those results you shared?

@ryansolid Here is the result after removing all styles for vanillajs-custom-el and vanillajs-shadow :