Initially, Web Components were put forth as a way to replace JS UI frameworks like React, Angular, and Vue. But it turned out that WCs don't solve the same prob

Initially, Web Components were put forth as a way to replace JS UI frameworks like React, Angular, and Vue. But it turned out that WCs don't solve the same problems as frameworks. Frameworks solve three problems: 1) Encapsulation. The DOM APIs don't make it easy to encapsulate reusable UI components. WCs help here. 2) Efficient re-rendering. The DOM APIs don't make it easy to manage client-side state variables, re-rendering just the UI parts that need changing. Unfortunately, WCs don't solve this problem; Shadow DOM slots (sub-components) render eagerly, whether you like it or not. https://twitter.com/tomdale/status/1153309794226147330 https://twitter.com/tomdale/status/1153309794226147330 3) Quirks. DOM APIs are quirky; they were developed organically by web standards committees. They have a bunch of (well documented) gotchas that you have to work around, making them inconsistent and clunky. WCs don't smoothe over any existing quirks; it just adds more of its own. https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci... (My favorite WC quirk: WCs don't render at all if the user disables JS. []) As a result, most WC advocates today recommend using a lightweight framework on top of WCs, e.g. Lit. In fact, most modern frameworks do allow you to use WCs transparently. (React makes you jump through some hoops, but you can* do it.) https://custom-elements-everywhere.com/ https://custom-elements-everywhere.com/ Why bother using WCs if you're using a framework? Because WCs can allow you to use the same component code in multiple different frameworks. Despite triumphalist anti-framework rhetoric when WCs launched, now the claim is more modest: WCs solve the problem of interoperability between frameworks. But if you're using exactly one framework, you don't need interop. Using multiple frameworks is an inherently unusual problem to have; big corps have this problem, but they're not proud of it, because each framework slows down the page. In conclusion, WCs are less popular than frameworks because frameworks solve more problems than WCs, and the interop problem that WCs do solve is very rare. [*] If the user disables JavaScript, WCs don't render at all. Traditional frameworks would render UI on the server side using plain old HTML and CSS, running JavaScript on the client-side to attach behavior after rendering. (Modern frameworks allow you to run the same UI code on the servere side and on the client side, re-running the UI code on the client to attach behavior.) But encapsulated WCs with Shadow DOM fundamentally change the web platform. WCs allow you to have multiple elements on the same page with the same ID (inside encapsulated containers). They prevent external styles from cascading into your component, and prevent your component's selectors from leaking out into the rest of the document, and they can do this in a hierarchy of sub-components. Cool stuff, but none of it works at all without JS, and trying to transmogrify Shadow DOM elements into non-Shadow DOM elements simply can't be done 100% of the time. (If you're careful, you can get it to work on carefully written WCs, but now you have new gotchas.)