November 9, 2023 at 10:14:32 PM UTC

	Since	posts	replies	likes	reposts and quotes	views
Bluesky	May 2023	1,039	8,236	23,127	2,380
Mastodon	Nov 2022	2,399	29,156	55,396	16,820
GitHub	Jul 2010	179	5,777 3,520	33,866	3,317
npm	Jul 2014	139	1,546			75,991,720
YouTube	Dec 2015	30		1,203		32,713
Letterboxd	Mar 2026	55
Blog	Nov 2025	20
Hacker News	Jan 2011	59	575	802
All	Jul 2010	4,807	37,967	114,394	22,517	76,024,433

Confession: in my Web Components journey I’ve used Shadow DOM on a few components and it made sense to do so and it worked well (no regrets).

Remember that these different styles of component are tools in the toolbox.

Shadow DOM isn’t a silver bullet (or even a good default choice) but when you understand the tradeoffs you’re making and weigh those against the purpose and use case of the component, it sometimes makes sense to use it!

(And if you’re new to Web Components, don’t start here)

29 replies

Sascha Karnatz 28 min later

@zachleat at the moment Web Components are my silver bullet.
1. Zach Leatherman 41 min later
  
  @_web_ glad you’re getting mileage out of them!
bkardell 1 hr later

@zachleat
1. bkardell 1 hr later
  
  @zachleat Jk this is a perfect and nuanced twoot. A+
  10/10
  1. Zach Leatherman 1 hr later
    
    @bkardell feel the shadow dom flow through you
    1. Stuart Langridge 1 hr later
      
      @zachleat @bkardell "this is how it feels to be Anakin Skywalker, forever: the light DOM burns you. It will always burn you"
    2. Private reply 5 hr later
Chris Coyier 2 hr later

@zachleat I'm super down with "Shadow DOM is not a good default"
1. Doug Parker 🕸️ 4 hr later
  
  @chriscoyier @zachleat I'm curious to hear what you both think are the common "default" problems Shadow DOM fails to solve?
  Are there any specific shortcomings where you think there are better alternatives?
  1. Chris Coyier 4 hr later
    
    @develwithoutacause @zachleat It's styling for me. ::part and custom properties sneaking through are not real styling solutions. Plopping a chunk of CSS into a template literal I think is clunky and weird. Adopted stylesheets are another request and also weird. So just screw it. Light DOM. I want to use my regular CSS to style things. *generally*.
    1. jake lazaroff 8 hr later
      
      @chriscoyier i’m also in this camp, but slots are only usable with shadow DOM. @justinfagnani proposed “open-stylable” shadow roots which seem like the best of both worlds: https://github.com/WICG/webcomponents/issues/909
      @develwithoutacause @zachleat
      1. Doug Parker 🕸️ 9 hr later
        
        @jakelazaroff @chriscoyier @justinfagnani @zachleat I get the need, but I feel like open-styleable is a nuclear option.
        I'm all for improvements to APIs like CSS parts, and I'd rather fix those than throw away style isolation altogether.
        
        Zach Leatherman 18 hr later
        
        @develwithoutacause @jakelazaroff @chriscoyier @justinfagnani I love the style isolation too but requiring shadow DOM for this jumps ahead a few steps for me! Is it future-feasible to get slots and style isolation with light DOM?
        
        Thomas Broyer 20 hr later
        
        @zachleat @develwithoutacause @jakelazaroff @chriscoyier @justinfagnani
        It makes no sense to me to use slots without shadow DOM.
        How do you envision this being used and how it would work?
        I mean, if you're "just" cloning a template to replace the initial light DOM, it's 10 lines to `querySelector` the initial children and move them to the cloned template & replace children.
        → https://codepen.io/tbroyer/details/vYbmbXx
        But that's not really "slotting" for me: you lose dynamic manipulation of slots/slottables.
        
        Thomas Broyer 20 hr later
        
        @zachleat @develwithoutacause @jakelazaroff @chriscoyier @justinfagnani
        Wrt style isolation, would a CSS reset within @scope (with a lower bound) work?
        (I did use CSS scoping in the above pen, but didn't add a CSS reset)
        
        jake lazaroff 22 hr later
        
        @tbroyer it would just transclude the slotted content in place of the <slot /> element, no? basically the same as react children/svelte slots/etc
        @zachleat @develwithoutacause @chriscoyier @justinfagnani
        
        Thomas Broyer 23 hr later
        
        @jakelazaroff @zachleat @develwithoutacause @chriscoyier @justinfagnani Show me some code 😉
        (what you write in the HTML and JS, and what the final DOM looks like: because without shadow dom, the light dom is modified, how could you have transclusion rather than moving nodes around? react/svelte are different, they create the DOM from scratch whereas WCs start with DOM children already)
        How different would it be from what I did in this pen?
        
        jake lazaroff 1 day later
        
        @tbroyer haven’t been at a computer all day so can’t inspect the resulting DOM tree in your pen, but i think i’m describing what you seem to be doing. tbh i’m not really opinionated about the implementation; i just think this particular cow path is extremely well traveled, so we should pave it. it’s nice that it can be done in userland but imo the platform should provide a solution too.
        @zachleat @develwithoutacause @chriscoyier @justinfagnani
        
        Justin Fagnani 1 day later
        
        @jakelazaroff @tbroyer @zachleat @develwithoutacause @chriscoyier light DOM slots just aren't really possible.
        Any proposal would have to describe the assignment algorithm: what nodes are slotted where. I haven't seen anyone do this, because... there's no way to tell what element any slot actually belongs too, so what elements are potentially slottable, and then how to avoid circularity issues.
        Shadow DOM solves this with two trees, and I think two trees are just necessary.
        
        Justin Fagnani 1 day later
        
        @jakelazaroff @tbroyer @zachleat @develwithoutacause @chriscoyier this is why I think the solution to a few shadow DOM problems is to decouple the encapsulation features, because slots are the most fundamental thing that SD does, and you can't get interoperable composition other ways.
  2. Zach Leatherman 18 hr later
    
    @develwithoutacause @chriscoyier ah I did a whole talk on this! 😅
    https://www.zachleat.com/web/jsheroes/ is probably the best video of it—I wish I had a blog post representing the thoughts in the talk, hmm
2. Raphael 7 hr later
  
  @chriscoyier @zachleat
  I think context is important here regarding defaults. For my personal components I‘d rarely use Shadow DOM, but for a lib with a lot of uncertaint usage scenarios and distribution on a per-component basis, Shadow DOM seems like a reasonable default in a lot of cases.
Paddy 2 hr later

@zachleat is there a write-up you recommend (offhand, I can Google myself if you don't have one in mind) of the trade-offs?
1. Zach Leatherman 18 hr later
  
  @paddy I did a talk on this topic! https://www.zachleat.com/web/jsheroes/ (I need to write a blog post too 😭)
  1. Paddy 1 day later
    
    @zachleat I'll take it, thanks!
Mayank 4 hr later

@zachleat there are many good use cases for shadow dom!
ultra isolated content like data visualization, animated illustrations, ads, third-party widgets, video players, 3D objects…
these use cases are very specialized, and will only form a small percentage of most websites consist of
1. Dave 🧱 18 hr later
  
  @hi_mayank @zachleat would you say Shadow DOM is good for obscuring complexity that isn't needed for the user?
  1. Zach Leatherman 18 hr later
    
    @DavidDarnes @hi_mayank it’s the DOM we pile into the closet and say our room is clean
Bob Monsour 4 hr later

@zachleat Good to know as I have yet to start the journey.