Clarify the relationship to Shadow DOM standard

[Serhii Kulykov]

Hello. I took a look into your project and the positioning is confusing. Especially, using "shadow" makes an impression of something close to Shadow DOM.

But in fact, there are only few statements which I was able to find. Let me elaborate a bit more on how I see your position as a developer and what impression does it make.

Position

The first sentence in the description says the following:

reshadow provides the Shadow DOM developer experience

At the same time, in "motivation" section there is a vague critique:

We also have Shadow DOM, which can fix some kind of that problems like styles isolation, but there are also some tradeoffs, and it often doesn't fit to the requirements.

And the key statement, to my understanding, is the following one:

It is possible to write HTML and CSS (...) like there is nothing else than just the Component.

Impression

Let me wrap this up in a following way (and please correct me if I'm wrong):

1. You acknowledge that there is a standards-based way of CSS encapsulation

2. You agree that using Shadow DOM in certain cases has positive sides

3. You create yet another solution relying on global CSS, and try to mimic the way of how users write CSS when using Shadow DOM, because native way "doesn't fit to the requirements."

Summary

I would really appreciate if you expressed a more clear position related to Shadow DOM:

1. What exactly tradeoffs does it have for your project? (i.e. having to bundle CSS with JS sounds like a valid excuse to have global CSS, until we have native CSS ES modules)

2. What exactly are your requirements that Shadow DOM doesn't meet? (i.e. having to support IE11 or let's say old iOS versions would be a valid excuse as well).

My only point here is responsibility. As long as you call the library reshadow and claim that it does the job for you better than Shadow DOM could, an implicitly negative message that someone could read between the lines immediately appears.

---

Please don't treat this as an offense. Actually, I think that even mentioning Shadow DOM in more or less neutral to negative way might be for good.

Feel free to close the issue if that's not a proper place for such a discussion.

[Anton Kastritskii]

Hi, thank you for the issue and the interest in the project! I am currently on a holiday and don't have time to write a detailed reply. I will be back on Monday and will post a full answer for your concerns.

[Anton Kastritskii]

First of all I would like to thank you for the interest in the project and writing up such a detailed issue.

In order to clear out any further confusion I want to state that I really enjoy the ideas that shadow DOM and web components provide us. Our docs are not ideal and we actively working on them to the limit of our free time. Our documentation definitely has room for improvement and we look forward to making it even better. I know that I am going to add a few points thanks to your issue in order to avoid confusion for future users.

Now to answer your questions. I am going to list all the things that I think should cover both of your questions:

• As you already stated unfortunately we do need to support IE11
• SSR. As far as my knowledge goes there is only one way for a web component to look like an inited element before the js is loaded is by inlining styles and that can quickly bloat your html. This specially becomes an issue when SSR plays a big role in the conversion on your project.
• Style reuse. Complete style isolation is great but it can play a rather poor role when almost in every project we have things like normalize.css or our own global css that we want to apply on all elements(mostly typography). At least as far as I know.
• Style encapsulation does not cover css custom properties. We all now that name collisions happen and reshadow solves that by hashing its names.
• A/B testing. It is not really trivial to do experiments using shadow DOM. Reshadow on the other hand makes it fairly easy to compose styles which allows us to simplify restyling process for A/B testing.
• Performance. Here is an illustrated example. On my machine when I try to render 1000 elements reshadow does it in 170ms and WC in 450ms, when I try to render 10k I get 1873ms and 5229ms respectively. Sure, it is a synthetic benchmark but it illustrates the difference presence pretty well.
• Reshadow is not just about dom, but the semantic approach overall. Personally I love what DX react provides and love just some of the features that shadow DOM provides. Reshadow is an approach to get the best from both worlds. This approach has worked for us and we shared it to see if it may work for other people too.

There is also a really good post by Rich Harris where he mentions some of the same things and others too.

On a side note I want to say that shadow DOM is great. When working on a smaller project I would
definitely consider using it. Reshadow was born from a pain in having to solve complex styling issues in a company with a really large react code base and hundreds of front end developers. Changing the stack in such situations is rarely a way you want to go.

I hope I’ve answered your questions. If anything remains unclear please let me know and I will be happy to expand on anything confusing. If this is pretty much it. Feel free to close the issue =)

[Serhii Kulykov]

Thanks for the detailed clarification. I agree the original questions are answered.
Let me add some notes as well, for sake of completeness, just in case someone else reads this.

Complete style isolation is great but it can play a rather poor role when almost in every project we have things like normalize.css

Constructible stylesheets are intended to solve that. However, with recent discussions on the API, and WebKit opposed to the original proposal, there is a chance that they will be delayed.

Style encapsulation does not cover css custom properties.

That's an interesting one, which I didn't consider previously. Expanding the isolation idea that far means getting rid of cascade. Given the fact that intention is combined with the desire to use normalize.css, then it sounds like you only need CSS cascade in certain cases.

To my understanding, CSS custom properties were designed in such a way that you can benefit from cascade, and especially when using Shadow DOM and :host selectors.

Performance. Here is an illustrated example.

IMO, the example rather indicates that there are missing peaces in Custom Elements. Especially, ElementInternals API would enable states like empty so we potentially could get rid of the workaround with slotchange event used here, which presumably affects the performance. I will play with the benchmarks a bit more to see what else could be improved.

Reshadow is not just about dom, but the semantic approach overall.

So it is when we are talking about Custom Elements, usually used with Shadow DOM (but not always, as you can also add Shadow DOM to div). They serve semantic approach as well.

Overall I must admit that your motivation makes sense and the technology choice is clear to me.

PS: I definitely didn't want to raise another "web components vs React" issue, neither "web components vs Svelte" or anything else like that. Feel free to lock the conversation if you wish.