Unfortunately, as most of them left Twitter they also temoved all their accounts, so you can only see responses from framework authors like Rich Harris. But here's a very on-brand toot from Alex Russel: toot.cafe/@slightlyoff/1132222807127588… This is the article he's reacting to: dev.to/ryansolid/web-components-are-not…... --- Or here's Lou Verou (a TAG member) calling it hate (this is the mildest reaction, btw): x.com/LeaVerou/status/18401346548522477… and uncritically reposting a bullshit article calling it excellent x.com/LeaVerou/status/18397369083705879… (see reaction by Vue author: x.com/youyuxi/status/1839833110164504691 and x.com/youyuxi/status/1839834941884121363) Note that Lea Verou also says that people decided to fix some things around web components after her post in 2020: lea.verou.me/blog/2024/wcs-vs-framework… Here's Rich Harris (author of Svelte) in 2019: x.com/Rich_Harris/status/11983323985613… Here's the 2022 Web Components Group report: w3c.github.io/webcomponents-cg/2022.html. Notice similarities? Literally everything web framework authors have been saying for ever has been completely ignored in favor if the in-group/tribe. Literally nothing has changed. Nothing at all.

> Web components have their place but they're no panacea and the ecosystem is still pretty young. And yet wc proponents keep pushing them as if they were panacea. And "ecosystems is young" is a funny statement for something that is entering its 12th year of development (and fifth year of wide availability in browsers). > The current native feature set is somewhat lacking so you're definitely going to want to augment with some sort of helper framework/library. If they are lacking, have glaring unsolved issues, twitter.com/Rich_Harris/status/11983323…), and you still need to augment them with a framework/library,... what's the point then? If any of the existing solutions had the same amount of issues that wcs have, they would never have gotten of the ground. And yet here we are 12 years and hundreds of millions of dollars of effort later

> I'm curious what the problems are with web components that you see? Bitesized explanation from Rich Harris, the author of Svelte: twitter.com/Rich_Harris/status/11983323… It's from 2019, but all the issues are still there. When/If they are going to be solved, it will be by increasingly complex standards that require more and more Javascript for them to just barely function (like they couldn't even participate in form events without additional Javascript). See also a larger discussion by the author of Solid: youtu.be/BEWkLXU1Wlc?t=5837 (if the link doesn't open at the timestamp, skip to "Failed Promise of Web Components" at 1:37:17). It's a bit rambling because it was unrehearsed and on stream, but still good. He also shows and discusses other articles like Rich Harris' dev.to/richharris/why-i-don-t-use-web-c…... and his own dev.to/ryansolid/maybe-web-components-a…... You can read them directly, but Ryan gives excellent additional context.

Because it was pushed and is being pushed primarily by Google and its devrels. After 12 years in development they are barely usable, have a ton of issues that are not resolved [1] and [2], and any client library in the same state would be laughed out of the room by anyone. However, there are now hundreds of millions of dollars of sunk costs, dozens and dozens of specs, unbelievable complexity that infects all other actually useful specs (like Scoped CSS which cannot proceed properly because effing Shadow DOM), extreme zealotry and complete unwillingness to engage with anyone even mildly critical of web components. All this results in a strong desire to keep going and promoting this even if no one can even say what the "done" state is for them. Or what is the actual goal, since that goal changes every few months. [1] twitter.com/Rich_Harris/status/11983323… None of these have any satisfactory solution (for some not even on the horizon) [2] Even the people pushing this stuff realise how many issues they have: w3c.github.io/webcomponents-cg/2022.html See how many of those are not even close to even being discussed

Because they don't offer a lot of things that matter to a lot of folks. This is still true 4 years later: x.com/Rich_Harris/status/11983323985613…

> Web Components give the basic blocks of writing those frameworks easier. No, they don't. Both for the fact that they need 20 more web specs to fix issues that none of the frameworks have, to the fact that they are actually pretty bad as basic building blocks: you can't control their rendering (once a web component is on the page, it will eagerly render, and will pull in and render whatever imports it has); shadow dom breaks all sorts of expectations; each is an isolated rendering block, so you can't control for batch rendering; there's no server-side rendering story to speak of, and that's only off the top of my head. There are many more tehcnical reasons than I listed, but I'd have to hunt them down. There are many, many, many reasons why even the authors which originally really rooted for web components, and modeled their frameworks after them now moved awaya from them completely (Solid, Svelte, Vue). There are also many, many, many reasons why even the new framework overwhelmingly _don't_ use web components for anything. There are a few thoughts^ - Ryan Carniato (Solid): dev.to/ryansolid/maybe-web-components-a…... - Ryan Carniato's stream on web components: youtube.com/watch?v=BEWkLXU1Wlc (you can skip to 1:37:17 for a specific discussion) - Rich Harris (Svelte): dev.to/richharris/why-i-don-t-use-web-c…... - All these issues are still there, 4 years later: twitter.com/Rich_Harris/status/11983323… and so on and so forth. > but JSX does not run natively in the browser. WCs do. There are compromises. JSX is probably the absolute last thing frameworks care about. They do care about things like not jumping through hoops to make things work.

> Now that I can leverage Web Components, I don't see a real need for React as the browser is very capable. Except for the long list of issues that WC proponents pretend doesn't exist: twitter.com/Rich_Harris/status/11983323…

>Except for the long list of issues that WC proponents pretend doesn't exist: twitter.com/Rich_Harris/status/11983323… This is the sad reality for web components. You end up needing so many libraries to do basic things that a framework would handle, that your project just becomes a defacto custom framework.

> I don't understand why people don't base their apps and frameworks off of standard browser and JS supported techniques like custom elements Because 12 years after their idea was pitched Custom Elements still suck? Just a tiny list of problems with them, with big consequences: twitter.com/Rich_Harris/status/11983323… > and template literals with tag functions like Lit The whole field of programming has taught us not to use string-based programming and not to rely on regexps for parsing said string based programming to arrive at results. Also. Why are you against JSX and React, but at the same time happy with such "standard" things from Lit like magical reactive properties and bullshit like ".value=" and "?hidden=" and "@click=" none of which are standard browser techniques. > for choices like JSX that were made in the past when these standards weren't available yet What standards? Very few frameworks want to touch custom components with a ten-foot stick. Yes, most can target them, but very few have the as the underlying abstraction because they are just horrendously bad.

> Wouldn't rehydrating the specific page which uses web component eliminate the need for explicit SSR support in the JS framework Erm.... No. If you don't have SSR then it doesn't matter if it's web components or not: they will be instantiated at runtime. > it comes down to whether the framework has good support web-components or not in the first place? All of them have decent support for web components (at least for "consumption"). The reasons they don't support them as a foundation (and at most emit web components if you tell them to) is that they don't want to deal with all the stuff like no SSR support, the need to still have all the layers above for things like lazy loading, progressive enhancement and a whole laundry of issues that none of the non-web-component frameworks have: [1][2] [1] Why I don't use web components dev.to/richharris/why-i-don-t-use-web-c…... [2] twitter.com/Rich_Harris/status/11983323…, explanation on SVG: twitter.com/Rich_Harris/status/11983396…

> What am I missing, what's the elevator pitch for web-components and shadow DOM? There's none except the oft-repeated "use the platform!" (as if other frameworks and libraries use something else, and not the platform). Currently web components work, if: - you have a large distributed team, and - you need to have consistent elements and styling across many properties, and - your components can be expressed as "leaf elements". That is, view-only elements. No forms, no state, only presenting some data. Beyond that the elevator pitch is "for the past 10 years, and counting, we've been bravely trying to fix the ever-growing list of problems that web components introduced by simply being. And we're solving that by throwing more and more javascript at the problem". A very non-exhaustive list: twitter.com/rich_harris/status/11983323…... And things like participation in forms? It's "solved" by adding Javascript: web.dev/more-capable-form-controls/ Which is ironic, given that the original pitch was "we're piling more and more into Javascript, and we shouldn't" fronteers.nl/congres/2011/sessions/web…...: --- start quote --- I think we’re stuck today in a little bit of a rut of extensibility. We wind up leaning on JavaScript to get things, because it is the Turing complete language in our environment. It is the only thing that can give us an answer when CSS and HTML fail us. So we wind up piling ourselves into the JavaScript boat. We keep piling into the JavaScript boat. Bruce yesterday brought up the great example of an empty body tag, and sort of this pathological case of piling yourself into the JavaScript boat, where you wind up then having to go recreate all of the stuff that the browser was going to do more or less for you if you’d sent markup down the wire in order to get back to the same value that was going to be provided to you if you’d done it in markup. But you did it for a good reason. Gmail has an empty body tag, not because it’s stupid. Gmail does that because that’s how you can actually deliver the functionality of Gmail in a way that’s both meaningful and reliable and maintainable. You wind up putting all of your bets, all of your eggs, into the JavaScript basket. --- end quote ---

> why would anyone want to subject themselves to framework lock-in when you can have components that are portable across frameworks? what are the arguments against? twitter.com/Rich_Harris/status/11983323… None of these are solved, or will be adequately solved in a forseeable future. Some of these will be addressed by ~20 new JS-only specs in the various states of "not started" w3c.github.io/webcomponents-cg/2022.html Literally none of the major (or even emergent) frameworks have these issues, or a chance of running into these issues.

Have Web Components solved any of these issues that don't exist in any of the "tired" frameworks twitter.com/Rich_Harris/status/11983323… ?

1. What "non-native" web standards does React work with? 2. Have the "non-hurting" web components solved all the issues that literally no other "no -native-standard" frameworks have? twitter.com/Rich_Harris/status/11983323… 3. Why is it that all the issues that arise from Web Components merely existing are "solved" by throwing more and more Javascript at the platform (anything from form participation to anything else, really) 4. Could it be that it is Google as the main driving force behind web components is the one hurting people by making the platform ever more brittle and unimplementable?