I have long been a supporter of Web Components over non-native libraries. Recently I tried to put together a native only site with them and it was a lot of fun. It's not without it's quirks or concerns, but for a smaller, non SPA site I would pick it over React or others just to cut out the tooling chain and node ecosystem cruft. It would save me some headspace at the very least.
I worked with early Polymer versions for about a year on a pilot project and loved the technology and implementation. Conceptually, I think its superior to lots of the alternatives.
Fact of the matter is that the javascript/nodejs (e.g. React) hordes shouted down a really fine set of ideas.
its a sad loss, IMO.
Not being familiar with "Web Components" (vs. web components), could an expert chime in with thoughts on why they don't appear to be catching on? That is, why are frameworks like React and Vue not leveraging this native browser capability?
Because there's essentially nothing to leverage. The one thing that they promise (interoperability between frameworks) is both not true in my experience and not compelling enough to warrant the massive amount of complexity required to work around their shortcomings. If you want nightmares go read Polymer or Oracle JET's source code, both are WC based frameworks, both had to go to extreme lengths to offer a semi-reasonable end user API.
> The one thing that they promise (interoperability between frameworks) is both not true
Who is promising that? Web components are just a set of APIs in the browser. All they can really do is make the same promise of all the other browser APIs, which is availability.
They lacked native support at first, and the spec wasn't (and isn't) complete. Even though they had polyfills, Web Components were being promoted at a time where not many understood the benefits of component based development. It was too niche, and the idea of SPAs or single page applications was just catching on. They broke the ground, but it wasn't until other frameworks made it easier and popular that the idea caught on and the tool made sense to more people.
In other words, the timing was off and now everyone is using React instead. To gloss over some of the technical details like state management, ES6 out of the box and how JSX probably made sense to some people more than the Web Components spec.
Why React and Vue aren't leveraging it is probably because it's easier to roll their own than keep up with the living specification, and because the way they approach components is a bit different.
There's that, and the fact that web component technology is really a set of convenient primitives that don't do anything better than libraries and frameworks, besides the fact that they come built in to the browser. Then of course there was the rash of bloggers who were huffing and puffing over how inferior web components are, despite how their existence and even the ability to define custom elements alone are a pretty good idea. From what I've read over the years, I think that there's been a lot of bad press early on, and perhaps there were some very misguided individuals who think that web components "fail" because they don't live up to React. The point was never to replace React. A lot of people are still complaining about the polyfills, even though the only thing it says about web components is that they will eventually have full support and not need polyfills. Above all, all the polyfills combined aren't even half the size of a lot of app builds in the wild.
To expect web components to "catch on" in the same way that React and Vue have is a bit dumb, but I would like to see them adopted in a way where there's a good story around their use in frameworks, rather than a replacement.
Vue and Angular are leveraging them. Given that some older browsers do not support the full spec, it is up to you to choose how the code gets generated.
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
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-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
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.)
Long story short: They solve a problem that is attractive to solve in a way that is not super useful for how most people want to develop an application. They're client side only (in practice) and poorly compatible. The developer problem they set out to solve is mostly solved elsewhere, better, by other frameworks. What those frameworks don't solve is usually not the parts that are useful about Web Components.
Which is a shame - as there are some genuinely good ideas in the set of tech that makes up Web Components. They just aren't very attractive to work with.
I kind of feel they need to scrap it and come up with a compelling v2 that uses what we know now.
Readit News
Should turn solid green.
I have changed the details a bit since this but the approach is the same.
The readme of that repo explains how I approached working with them, I tried to keep the process simple.
They solve the wrong problem the wrong way. The creator of Ember recently tweeted about this: https://twitter.com/tomdale/status/1153309794226147330
Who is promising that? Web components are just a set of APIs in the browser. All they can really do is make the same promise of all the other browser APIs, which is availability.
In other words, the timing was off and now everyone is using React instead. To gloss over some of the technical details like state management, ES6 out of the box and how JSX probably made sense to some people more than the Web Components spec.
Why React and Vue aren't leveraging it is probably because it's easier to roll their own than keep up with the living specification, and because the way they approach components is a bit different.
To expect web components to "catch on" in the same way that React and Vue have is a bit dumb, but I would like to see them adopted in a way where there's a good story around their use in frameworks, rather than a replacement.
https://vuejs.org/v2/guide/#Relation-to-Custom-Elements
https://angular.io/guide/elements
React community is kind of hostile to the WebComponents idea.
It literally says that Vue doesn't leverage Web Components. It is, however, interoperable with them.
> React community is kind of hostile to the WebComponents idea.
It's not. It's just more pragmatic. I've seen way more hostility from web component community towards React (and frameworks in general).
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
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-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/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.)
Which is a shame - as there are some genuinely good ideas in the set of tech that makes up Web Components. They just aren't very attractive to work with.
I kind of feel they need to scrap it and come up with a compelling v2 that uses what we know now.