| > If people still "have the wrong idea about web components", it's a testament to their failure. 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?