My HTML Web Component boilerplate for 2026(gomakethings.com)
gomakethings.com
My HTML Web Component boilerplate for 2026
https://gomakethings.com/my-html-web-component-boilerplate-for-2026/
5 comments
Yeah, I also used the Shadow DOM a lot working on a CMS that edit the website content “in place”: CMS UI was safely scoped inside my web components thanks to their Shadow roots, I never had to worry about arbitrary styles from the websites the CMS was loaded in colliding with internal CSS.
Shadow DOM exists for some specific use cases but it shouldn’t systematically used when creating web components.
Shadow DOM exists for some specific use cases but it shouldn’t systematically used when creating web components.
Interesting article, I think some points are covered by this ESlint plugin [0] specifically created for web components.
[0] https://github.com/43081j/eslint-plugin-wc
[0] https://github.com/43081j/eslint-plugin-wc
I know it's not the main topic of this article, but just to toss it out there, I have had really good luck with the Shadow DOM, but for a different use case of custom elements: "Late-as-possible FE Integration" For big chunks of UI representing features that reach meekly into another feature (think: comment threads+form on an article, or background process status widget), that are managed by another team and/or needs to integrate into many different front end apps with different architectures, the inflexibility is rather helpful.
The things that make THIS specific usecase a great one for Shadow DOM makes it awful for composing small custom elements into a bigger application. I agree there. But for gluing together entire features...
- You keep styles separate, so impact from an accidentally shared CSS rule is limited. This is a huge plus when you consider this other feature can be deployed totally out of sync with your hosting-application. They're feature is just some HTML/CSS/JS accessible internet, not a package.
- Events are neatly rewritten when crossing the Shadow DOM to lightly enforce a public interface. (The feature needs to emit events, don't rely on listening to a button IN another feature.)
- Issues with ARIA/AOM are generally limited if you commit to it being the integration medium: just 1 Shadow DOM root per big feature. That way references are at least scoped naturally to this chunk of the document. If something truly describes/controls something specific outside of the Shadow DOM, then IMO, it's not an independent feature. A feature should work generally on the current resource the URL represents.
- And best of all for my use cases, it can go anywhere HTML is. For strangler fig pattern refactoring [0], it's a massive help. Migrating by-feature rather than by-page speeds up how quickly the value of a refactor can be demonstrated.
[0] https://en.wikipedia.org/wiki/Strangler_fig_pattern
EDIT: Just realized the author just wrote about that, yesterday! https://gomakethings.com/no-seriously-the-shadow-dom-sucks/#...