Comment by troupo
2 days ago
Support for anything web components-related is a death by a thousand cuts both for the browsers and for the framework authors.
For the browsers:
Shadow dom breaks almost literally everything. It's a parallel world that exists on its own and that needs dozens of additional web standards to patch holes introduced by it. And delays dozens of useful web standards that now have to be aware of it.
On top of that nothing in web components is ever created thinking even one step ahead, and break multiple pieces of basic functionality. It's a collection of barely fitting patches. E.g. at first they couldn't send data in forms. Enter FormData. Oops, still cannot be a custom form submit button. Here's a 7-year old still unresolved issue: https://github.com/WICG/webcomponents/issues/814
For frameworks:
Framework authors have to patch all thise holes on their own. Because unlike web components they actually do care about standards and browser functionality. If styles don't work, forms din't work, code doesn't work etc. because of web components, it's the framework that will be blamed.
It doesn't help that there's an insane amount of work involved in figuring out all the ways they are broken. See for example: https://xcancel.com/Rich_Harris/status/1841467510194843982#m
100% agree, and for most heavy users it really doesn't really enable them to do build any kind of app they weren't already able to do before.
The web platform has been shit long enough that frameworks and build tools ended up getting around to working around many shortcomings that shadow dom and web component APIs seek to address (such as scoping css with css modules then css in JS, now whatever else the cool kids are using), and the end result has less runtime overhead.
So say React adds support for shadow dom, as a user building a SASS app why adopt these APIs when your build system already does these? The framework authors know this, and so it's unclear what they gain from directing resources into making these parts of the frameworks API.
The only reason I tried it in my toy render DSL, is it sounded fun and unlike react I don't have to worry about breaking 10s of thousands of apps if I do it wrong.
Like I found it useful because I was trying to avoid using a build system and local styles allowed me to clean up my styles without resorting to build steps. But I'm largely building tools for myself and I don't really care about load times, and this likely isn't a representative use case.