Adiós Shadow DOM

The Shadow DOM is a key feature of Web Components. According to javascript.info (the best resource for learning JavaScript in my humble opinion), the “Shadow DOM serves for encapsulation. It allows a component to have its very own “shadow” DOM tree, that can’t be accidentally accessed from the main document, may have local style rules, and more.”

You might be building an app with something like Lit and it’s working fine and it makes you productive, I’m happy for you. Web Components are fine, I believe there’s a case for them, and the Mux elements are beautiful.

But after working with the Shadow DOM intensively for more than two years now, I can earnestly say: all the trouble it causes completely overshadow any of the benefits.

To name a few examples:

• it can make accessibility very hard; here’s a post from Nolan Lawson, but there’s more.
• it’s very server-side rendering unfriendly, to say it softly. (There’s Declarative Shadow DOM, but that’s very far from a solution one can adopt today.)
• the learning curve is very, very steep; I felt comfortable with it only after almost a year of working with it, and —presumably like many others— I went into a love-hate relationship.

One of the most common problems Shadow DOM can help to avoid, CSS leaks —e.g. some third-party code affecting your app’s own styles unexpectedly— is nothing compared to any of the issues mentioned above.

I obviously don’t know whether the Shadow DOM was a bad a idea in the first place, or whether it was badly implemented (it could be both), I just know I am no longer using it and will advice against it by default.

Shadow DOM is just not worth it. So thank you, and goodbye.