In comparison, Angular is a monster, and React is designed for the old browser capabilities, and is now staying around by inertia, not by inherent quality.
Funny you should say that when the current advise for web components is to avoid Shadow DOM (almost like the plague)
> no web components
As in?
> no template strings
Why would React need template strings? React is not the only framework that doesn't use template strings for anything (Vue, Solid, Svelte come immediately to mind). And it's hard to accuse those of being behind the times when Solid is literally the reason for the upcoming native signals proposal
Yes, there are some people who say to build web components without shadow DOM, but I'm convinced they're only building leaf nodes so they don't need composition with slots. As soon as they try to build any kind of container element they hit big problems.
--- start quote ---
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
--- end quote ---
And probably continued in HTML Web Components https://blog.jim-nielsen.com/2023/html-web-components/
A more technical and measured take on Shadow DOM is here: https://nolanlawson.com/2023/12/30/shadow-dom-and-the-proble...
> People coming from React-land can have a hard time reasoning about the difference between a custom element and a template render function and when best to use each
> This abuse of the component system can indeed lead to a massive explosion in nodes on a page and the performance tanks because of that
I know I certainly have that hard time deciding when I need a custom element and when a render function.
Unless you actually care about the web and its users. Then it turns out it's a very wise advice.
https://w3c.github.io/webcomponents-cg/2022.html
Web Components Community Group: 2022. You are one of the authors:
--- start quote ---
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM.
...
Selection does not work across or within shadow roots. This makes fully-featured rich-text editors impossible to implement with web components. Some of the web's most popular editors have issues that are blocked on this functionality
...
Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM.
--- end quote ---
Those are just the tip of the iceberg as these are very explicitly stated in the doc.
Then there's the issues of shifting the responsibility to both developers and consumers to handle Shadow DOM correctly.
Styling/themeing is still pain despite several different specs like shadow parts.
Don't use styles in your components too much, use Javascript to inject CSS into document and shadow trees or else there will be performance impact https://w3c.github.io/webcomponents-cg/2022.html#constructab...
Don't use too many shadow roots or there will be performance impact https://front-end.social/@5t3ph/115135994774490769 (linked in the sibling comment by @azangru)
You can't participate in forms until you write more JS for it, and still your submit buttons will be broken with no solution in sight.
etc. etc.
You don't have to take my word for it. Here's Nolan Lawson, emphasis mine:
--- start quote ---
https://nolanlawson.com/2022/11/28/shadow-dom-and-accessibil...
Shadow DOM is a kind of retcon for the web. As I’ve written in the past, shadow DOM upends a lot of developer expectations and invalidates many tried-and-true techniques that worked fine in the pre-shadow DOM world.
--- end quote ---
That's not true. Web components that render nothing will contain only their children as nodes, that's good enough for a good amount of container use cases.
So you can have something like:
<uix-modal>
<uix-button icon="wifi"></uix-button>
<dialog>
<div class="flex flex-col gap-4 p-4 w-[640px]">
...
</div>
</dialog>
<uix-modal>
All there is to say was said years ago. Today it should be enough to know that, for example, "form associated custom elements cannot be a submit button" issue was opened 6 years ago, in 2019: https://github.com/WICG/webcomponents/issues/814
In 2022 web component group report mentions it in passing: https://w3c.github.io/webcomponents-cg/2022.html#concerns-10
That issue is still open.
Or that web components breaking ARIA was known at least 2019: https://x.com/sarahmei/status/1198069119897047041 and this will not be fixed for another 4-5 years at least.
Imagine if any web framework had issues like that.
That doesn't even begin to cover things like "now every useful spec has to be acutely aware of Shadow DOM shenanigans" which delayed any number of specs like scoped CSS etc