webcomponents

n 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

ely aware of Shadow DOM shenanigans" which delayed any number of specs like scoped CSS etc

literal verifiable facts a biased outlook from a framework developer etc. > Look, the current web standards, and Web Components in particular, aren't perfect. I'm certainly not a fan of some of the design decisions. But they're tools that in conjunction cover a large amount of functionality that modern web frameworks simply ignore or reinvent. This is what I'm saying is a mistake. Just a few issues with this "tool" that is not perfect, but must be used. Note, this tool has been in development for 14 years this year, and literally none of the "huge bloated frameworks" have this issue. Note that all of these are from the Web Component Working Group report. They themselves wrote about these issues. And these all are issues that "biased" framework developers had been talking for literal years before this report even saw the light of day: - ARIA is broken. Needs a separate huge JS-only specification that is only now being slowly developed: https://w3c.github.io/webcomponents-cg/2022.html#cross-root-... See a larger description of the issue here: https://nolanlawson.com/2022/11/28/shadow-dom-and-accessibil... - CSS cascade and theming is broken. Needs several new specs to function, many of them JS-only, some already shipped, some still just being developed: https://w3c.github.io/webcomponents-cg/2022.html#constructab... and https://w3c.github.io/webcomponents-cg/2022.html#css-module-... and https://w3c.github.io/webcomponents-cg/2022.html#css-propert... and https://w3c.github.io/webcomponents-cg/2022.html#custom-css-... and ... - Document selection is broken https://w3c.github.io/webcomponents-cg/2022.html#composed-se... - Form participation is broken as it requires additional Javascript per each component to just participate in forms. Buttons inside shadow roots still cannot function as submit buttons: https://w3c.github.io/webcomponents-cg/2022.html#form-associ... and https://github.com/WICG/webcomponents/issues/814 And that's before we get into how they break many other things. Like the fact (that you labeled as biased) that using custom elements-aware APIs leads to a 30% drop in performance. > `template` is just one building block. You can use it alongside others to do things frameworks can do, except... without a framework! What a concept, I know. And end up making your own lib/framework in the process. Unless, of course, you want to pretend that all the issues above are nothing to talk about. > That code is standard HTML with JS in data attributes that does get interpreted at runtime, but it's not an HTML-like DSL that gets parsed and compiled into JavaScript—it is HTML. That's not JS, and it's not interpreted at runtime. It's painstakingly parsed with regexes, and then certain code is executed based on the result of that parsing. Somehow "fake HTML" is a no-no, but fake JS? Yeah, go ahead.

an't have slots. And without slots you don't have interoperable composition and you don't have viable container elements. You need some way to place children in an element that isn't confused with the element's own DOM. So to me, before encapsulation and style scoping, interoperable composition is the most important feature, and that's really why Lit defaults to shadow DOM on. Without it we'd need some special `.children` property and Lit's component composition suddenly wouldn't be compatible with everyone else. But the style encapsulation is often a major pain for developers, especially if they're trying to integrate web components into an existing system with whole-page stylesheets. It's a big blocker to a lot of design systems porting to web components. That's one reason I proposed something called "Open Styleable Shadow Roots"[1] which would let styles from outer scopes cascade into a shadow root - a way to break open style encapsulation but keep slots. It's been hard convincing browser vendors that this is needed, but I'm holding out hope that it makes progress soon. [1]: https://github.com/WICG/webcomponents/issues/909

to potentially allow attacks). [1]: https://github.com/WICG/webcomponents/issues/645 [2]: https://heximal.dev/ (Sorry the site is messed up on mobile. I need to fix it!)