Chrome does as well. The only one I'm not sure about is Safari.
Maybe @jensimmons.bsky.social knows.
@stuffbreaker.bsky.socialBurton Smith
@stuffbreaker.bsky.social
Fun-loving coder and speaker. I love web development, web components, and design systems. Creator of the WC Toolkit. I work at ZocDoc.
@stuffbreaker.bsky.social@stuffbreaker.bsky.socialI support this message
@stuffbreaker.bsky.socialHere's a simple demo I did with FAST web components running in Storybook! 🤌
@stuffbreaker.bsky.socialThe fact that you can run a GitHub repo directly in @stackblitz.com, is just awesome!
@stuffbreaker.bsky.socialEven that second queue is much faster than it used to be. It could be a few seconds or minutes. Either way, shadow DOM does not negatively affect SEO.
@stuffbreaker.bsky.socialYep! All pages get added to a render queue regardless of JS. If your app is using async content or what they call the "app shell model" where your app is rendered from a single anchor node, it will be added to a slower queue.
@stuffbreaker.bsky.socialWave 2 is reserved for async data/content loaded by JS and typically indexed much later. Local JS will be loaded and indexed in wave 1 including JS defined custom elements that don't use async data.
@stuffbreaker.bsky.socialCalling all fellow web devs, design engineers, and web components nerds!
Would you be interested in a #WebComponents conference??? Let us know!
@stuffbreaker.bsky.socialOne point of clarification I want to add is that the contents of JavaScript defined custom elements / shadow DOM are discoverable by web crawlers, so SEO shouldn't be an issue.
@stuffbreaker.bsky.socialThe sweet spot - good DX and good UX. 🤘
@stuffbreaker.bsky.socialAgreed! That's one of the reasons I've been rolling out these new articles about CSS-only custom elements. We should be able to have good developer ergonomics like auto complete, type checking/linting, and inline documentation without having to rely on JavaScript or framework components to get them.
@stuffbreaker.bsky.socialHopefully, we can get to a point where those aren't mutually exclusive.
@stuffbreaker.bsky.socialNot necessarily. This is a single aspect of that feature. It's all about your needs. I'm also a big fan of class utilities and CSS-only custom elements with no shadow DOM. Shadow roots aren't the right solution for every problem and performance shouldn't be the only hook you hang your decision on.
@stuffbreaker.bsky.socialIn global CSS, selectors like .card .title or .list > .item + .item can force the engine to check many more elements across the page.
@stuffbreaker.bsky.socialThe second is invalidation. When a class or attribute changes, the engine uses "invalidation sets" to decide which elements need restyling. Those sets are built per scope, so a change inside a shadow root only invalidates against that scope's selectors.
@stuffbreaker.bsky.socialSo with 1,000 components, each element is matched against a handful of rules instead of one giant global stylesheet.
@stuffbreaker.bsky.socialThe first is rule matching - each shadow root has its own set of style rules. An element inside it is only tested against its own scope's rules. Document-level rules are never tested against shadow content, and shadow rules are never tested against the rest of the page.
@stuffbreaker.bsky.socialSorry, you are correct. Recalculation is what I was referring to. The shadow DOM helps in two ways:
@stuffbreaker.bsky.socialThe shadow DOM can actually improve page performance. Because the styles get rendered in DOM fragments, selectors get applied to smaller DOM trees and repaints stay scoped when content gets updated.
@stuffbreaker.bsky.socialI'm checking this out! Thank you!