These are some disadvantages of webcomponents that I can think of.
- Can't register multiple versions of a webcomponent. Let's say you are using "x-dropdown"@2.0.0 which depends on " x-icon"@2.0.0 and "x-menu"@3.0.0 which depends on " x-icon"@1.0.0. Your app will crash because html tags can't have multiple versions ("x-icon" 2.0.0 and 1.0.0). It makes handling big projects a nightmare. And there are name collisions too.
- Not all properties can be serialized into attributes as strings, so you end up just binding properties. Boolean attributes have special are weird when used in the javascript side (an empty string is treated as a boolean)
- The shadow dom can be too restrictive and inflexible. Implementing portals for instance, requires using ugly hacks that depend on your webcomponent framework.
- Some complex webcomponents are not interoperable among different frameworks.
- Static analysis on webcomponents is poor and fragile. Compare declaring types of events in webcomponents, to declaring types of event handlers in react.
Chrome Dev Tools are also, at least in part, built with web components.
It's not web components that were working for them at scale, but Polymer.
They would've probably nebver completed anything with Web Components alone due to how horrendously bad their API is. You can compare Web Components API and Polymer API here: https://twitter.com/dmitriid/status/865518972380237825
It still took them over two years to switch from Custom Elements v0 to Custom Elements v1.
Also no browser vendors that flat out refuse to implement parts of the spec (Apple [0]), or block proposals unless implemented in a highly specific way (all, here's one example [1], ugh politics).
[0] https://bugs.webkit.org/show_bug.cgi?id=182671
[1] https://github.com/WICG/webcomponents/issues/587#issuecommen...
<template tag="test"><h1>works</h1></template> <test/>
But it's the same rationale IIRC why built-in components are not extensible (even if this was one of the original promises): the browser has no way of knowing about the actual behavior of the object, which leads to all kinds of mess inside the engine.
The validity of Apple's reasoning makes it even stranger.
Quite recently Constructible Stylesheets were released in Chrome:
- because lit wanted them
- despite Firefox and Safari being against the state of the spec
- despite Safari clearly stating they are not going to implement the spec, ever (there was a trivially reproducible race condition in the spec)
The entire discussion here: https://github.com/WICG/construct-stylesheets/issues/45#issu...
Custom elements are awesome for small things that don't need to appear in an SSR context (assuming you're using shadow DOMs). No, they don't support composable stylesheets, whatever those even are, but seriously, who really needs them? If what you are doing is complicated enough that the browser's native APIs are too obtuse then yeah go for something like React or Svelte. No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser. I'd use uncommon browser and language features if they made sense for a task.
The `<template>` and `<slot>` elements are really dopey and hard to understand. That's where something like React or Svelte comes in. Nobody would use either of those libraries if they didn't have better templating than the browser.
What is the idea behind Web Components? Does anyone have an idea of what they are, should be, and where they are going? They've been around for 10 years now. Google has poured literally millions of dollars into trying to make them happen.
If people still "have the wrong idea about web components", it's a testament to their failure.
> Otherwise, the people who say they "don't use" web components are being as unreasonable as it would be to say to not use the `<video>` element because it doesn't support all the things that `<canvas>` does with some 3rd party library for compositing.
Well, no. People who say "don't use web components" are very much aware about the fact that web components:
- at the core are 4 different standards. One of them is already fully deprecated (HTML Imports). The other one already has a deprecated and removed version (Custom Elements v0)
- introduced so many problems by simply existing that Google (primarily Google) has been pumping out literally thousands of pages of new specs just to fix the problems that web components created.
Problems: https://dev.to/richharris/why-i-don-t-use-web-components-2ci... and https://news.ycombinator.com/item?id=28697664. And new specs? Oh, they are introducing their own new problems: https://news.ycombinator.com/item?id=28698563
- have an API that is both too high level and too low level to be usable.
It's too low level and too verbose, so after several years of promoting them as "the be all end all components for the web" the narrative shifted to "it's just an API for library authors, you're not supposed to use them by hand". It's unusable at any significant scale. Google's own AMP has switched to using Preact to author their components because they couldn't bear it anymore.
It's too high level, so in the 10 years of its existence there are hardly any libs and frameworks that have adopted Web Components as the foundation. And even the new ones tend to skip Web Components. Well, most libs and frameworks can compile to Web Components, and can consume Web Components. But hardly any framework actually uses them as a foundation.
Well, I've linked to the dozens of problems that they introduce, so no wonder.
- "Custom elements are awesome for small things that don't need to appear in an SSR context"
that don't need an SSR context, that don't need a11y, that don't need to split SVGs, that don't need...
Too many "don't needs" for a tech that has seen millions of dollars poured into it, and 10 years of development. After all that it's still "it's awesome for small things". Only for small things.
Meanwhile, w3c has unveiled its own design system here: https://design-system.w3.org It uses SASS and it uses a third-party library to, quote, "enhance a <select> into and accessible auto-complete via JavaScript."
Imagine if millions of dollars and countless man-hours poured into Web Components were instead directed to make CSS better, to enhance the crappy built-in controls etc.? Oh, you'd have a better web, and not an "awesome for small things with dozens of problems".
> No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser.
Ah yes. I remember someone calling jQuery "the disappearing framework". Because its eventual goal is to be fully replaced by browser APIs.
It looks like Web Components' motto is "there's always someone doing stuff better in Javascript, so why bother, let's be crap".
> Nobody would use either of those libraries if they didn't have better templating than the browser.
Nope. People are using them not because of templating alone.
In a way, that's exactly my point. I don't get the need to view the related technologies as "web components". It's a branding error made to look niche features sound like something more than they actually are.
> It's unusable at any significant scale.
It's a fallacy to denigrate anything on the basis of scale, because not everything has to be at "scale". That doesn't have to be the job of web APIs. These tools exist to render things on web pages; they weren't intended to satisfy the needs of Google and their wannabes, as much as Google themselves believe otherwise (in seeing themselves as the arbiters of the web).
> Google's own AMP has switched to using Preact to author their components because they couldn't bear it anymore.
This seems like speculation. People switch projects to their framework of choice for any number of reasons, many of them not necessarily being objective. Preact is way cooler than custom elements, so of course there will be a bias towards using it no matter how useful or not useful custom elements are.
> Too many "don't needs" for a tech that has seen millions of dollars poured into it, and 10 years of development. After all that it's still "it's awesome for small things". Only for small things.
Again, not necessarily anyone's problem. Lifecycle hooks, templates, and shadow DOMs are missing features in a system where nodes can be inserted dynamically. Are they critical? No. Do they "scale"? Maybe not, but that's really not an argument against them being in existence. Frankly, I don't care if someone mistakenly thought they were a multi-million dollar idea.
> Well, I've linked to the dozens of problems that they introduce, so no wonder.
All of those arguments come from the premise that separate APIs are supposed to form something coherent. For one, I don't know how Chrome-only features are somehow supposed to be the fault of web components.
Custom elements are as inaccessible by default as non-semantic HTML elements. The use of ARIA attributes is pretty common for elements that are not custom.
If SSR is a problem then don't use shadow DOMs. If that's irreconcilable then use React or something that can scope CSS. Otherwise, a custom element can receive a role like anything else no matter what context it's rendered in.
> Nope. People are using them not because of templating alone.
That's not what I said. Templating isn't all that React and Vue do, but it's a make or break feature. Few would care about component lifecycle, reactivity, and other features if they had to verbosely hook into elements using regular JavaScript syntax. In particular, nobody would use Vue and especially Svelte if they had no templating. These "frameworks" are primarily templating libraries. React would have never taken off if there wasn't JSX.
> It looks like Web Components' motto is "there's always someone doing stuff better in Javascript, so why bother, let's be crap".
What exactly is the argument against that? HTML is crap, and for good reason. Browsers could have essentially become something along the lines of Adobe Flash, but instead they chose to be adequate for rendering pages. (some notable exceptions notwithstanding) Likewise, whatever "web components" are supposed to be, they add a few niche features to an existing system. Expecting bureaucratic web consortia to be wanting or able to compete with the likes of React is a path to disappointment.
Scale is "anything beyond the simplest of components".
> That doesn't have to be the job of web APIs. These tools exist to render things on web pages
Yes, that is exactly the job of Web APIs, and they are horrible even at rendering things on web pages. You'd have to search really far and really wide to find APIs that are as slow and as inefficient at putting pixels on screen like Web APIs.
But even beyond that, web components are a horrendously bad, overly verbose API that is unsuitable for, you guessed it, scale. Write a few of them by hand, and off you are looking for a framework or library.
> > Google's own AMP has switched to using Preact to author their components because they couldn't bear it anymore.
> This seems like speculation.
It's not speculation, but an overexaggeration. AMP project is pretty tight-lipped on the reasons why, but here's a big one: https://twitter.com/cramforce/status/1181927980467138560
--- start quote ---
The main issue was that handling attribute/children mutation got too complex when implemented manually instead of relying on diffing.
--- end quote ---
This is what I mean when I'm talking about scale.
> Again, not necessarily anyone's problem.
It is, ultimately, the problem of the people who will be using this tech.
> All of those arguments come from the premise that separate APIs are supposed to form something coherent.
No. All those arguments come from the fact that Web Components break all those things, are broken for all those things, and keep breaking a lot of other things despite everything that's poured into them.
And you can't just hand waive and dismiss all concerns with "who cares".
You have your project and someone brings a Web Component into it? Oops, your project can no longer be SSR'ed.
You have your project and someone brings a custom field into it implemented with Shadow DOM? Ooops, suddently your project has an inaccessible field.
And so on, and so on.
> The use of ARIA attributes is pretty common for elements that are not custom.
ARIA attributes do not cross shadow dom boundary. Web Components will break accessibility instantly just by virtue of existing (if they use shadow DOM).
> If SSR is a problem then don't use shadow DOMs.
Ah yes. "You're holding it wrong". That's the problem with web components: they break in so many common scenarios, that any other tech would be laughed out of the room. And yet, here we are, with people valiantly defending them.
> What exactly is the argument against that? HTML is crap, and for good reason.
HTML is crap, so let's add even more crap to it and be content with this crap?
> Likewise, whatever "web components" are supposed to be, they add a few niche features to an existing system.
That's the problem. The only features they add are "some niche features". The cost of developing, supporting and integrating these features has far surpassed any potential usefulness of these features. And their primary use case, still, is "yeah, maybe as some small dumb components if you don't use shadow dom, if you don't care about SSR, if you don't care about <a dozen other things that developers do care about>".
So what exactly is the idea of web component that everyone misunderstands?
- form participation without javascript hacks (they are called "an API", but it's a hack) https://web.dev/more-capable-form-controls/
- SSR
- splitting SVGs into components https://twitter.com/Rich_Harris/status/1354165883648827401?s...
- not breaking accessibility by default https://twitter.com/sarahmei/status/1198069119897047041?s=20
and a million other things, big and small
For simple components, especially stateless ones, React works well. When the component needs to manage user interactions it needs state, and then if you need to update props you have to make a new instance of the component, and that point React has failed in its promise.
Where did you hear that? React.Component has both props and state and both seem to work pretty well together, and you definitely don't need to destroy the component by changing the key property just because props changed.
https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...
That would suck and make React completely unusable, but it isn't true at all. Assuming that there are necessary state/prop interactions to track (sometimes the two arr largely orthogonal, so you don't need this) you might need to add additional state variables to do last value tracking for props, and then do (with useEffect hooks in a function component, for instance) state updates based on prop changes as needed, but you don't need a new instance on prop changes, generally.
https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...
React works fine with components that don't follow the recommendation, though if you freely mix internal state updates and external updates via props that shouldn't represent instance changes, you can very easily make something unnecessarily difficult to reason about. So the recommended pattern of either doing a fully-controlled or fully-uncontrolled component is a sensible recommendation that makes sense to guide design. But nothing will break and the React cops won't arrest you if you use props driving state, though if you do too much of that whoever had to maintain your code may be upset.
https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...
https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
ES6 multiline strings? Enhanced for convenience with a library like lit-html?