Getting tired of their framework-free narrative.
What they are doing is backing in the browser, via specifications and proposals to the platform, their ideas of a framework. They are using their influence in browser makers to get away in implementing all of this experiments.
Web Components are presented as a solution, when a solution for glitch-free-UI is a collaboration of the mechanics of state and presentation.
Web Components have too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex. These are incredible hard to use and full of edge cases. such ElementInternals (forms), accessibility, half-style-encapsulation, state sharing, and so on.
Frameworks collaborate, research and discover solutions together to push the technology forward. Is not uncommon to see SolidJS (paving the way with signals) having healthy discussions with Svelte, React, Preact developers.
On the other hand, you have the Web Component Group, and they wont listen, they claim you are free to participate only to be shushed away by they agreeing to disagree with you and basically dictating their view on how things should be by implementing it in the browser. Its a conflict of interest.
This has the downside that affects everyone, even their non-users. Because articles like this sell it as a panacea, when in reality it so complex and makes so many assumptions that WC barely work with libraries and frameworks.
> Web Components have too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex. These are incredible hard to use and full of edge cases. such ElementInternals (forms), accessibility, half-style-encapsulation, state sharing, and so on.
You could say the same about the DOM itself. That’s why frameworks were created in the first place. The Custom Element API is complex. The DOM is complex. It’s just that we’re used to the latter and not the former.
[dead]
I love web components, but the fact that there's plenty of shadow-dom piercing properties defeats their purpose of "author them once, reuse them in different applications".
One very common pitfall I encounter is the html's own base font size, since it impacts all the calculations in your webcomponents. Use a webcomponent with a font size of 12/14/16 and you get completely different behavior.
If they were truly isolated they would really scale, but they don't.
Not to nag, but this seems like a design error? WC font settings should be inherited and relative, rather than any specific pixel size. Designs should be robust enough to support overflowing text, should the user increase scale/zoom/etc.
Admittedly, I might not be understanding your problem well enough, so sorry in advance if I've mischaracterized the issue.
Shouldn't you be using relative units like rem anyways?
Yes, which makes it very difficult to make stuff work okay cross application at changing of base font and user's zoom.
Yes. But does my target market even know how to change those things?
Ideally, good ideas battle tested in various frameworks, would make it into the browser over time.
For example with signals https://github.com/tc39/proposal-signals
I agree that the original 4 parts of the web component spec ( custom elements, shadow dom, templates, modules ) had varying levels of battle testing and perhaps the most valuable ideas ( custom elements and ES modules ), were those which did have the biggest precedence.
> Frameworks collaborate, research and discover solutions together to push the technology forward. Is not uncommon to see SolidJS (paving the way with signals) having healthy discussions with Svelte, React, Preact developers.
This feels a bit deflective from the very real issue of in page framework interoperability - which is different from dev's taking to each other and sharing ideas.
What does battle tested really mean in numbers?
When people say battle tested what they are really doing is looking for bias confirmation. Its no different than when they say software becomes more durable due to community validation.
The only way to be sure is to actually measure things, with numbers, and then compare those numbers to some established baseline. Otherwise its just a guess. The more confident the guess becomes the less probable from the average it becomes. This is how rats out perform humans in weighted accuracy tests in clinical trials.
> What does battle tested really mean in numbers?
Not sure what you mean - are you asking number of users, length of time etc?
All I'm saying with this is that ideas which have actually been implemented, used and evolved, are much less likely to have rough edges than something that's never left a whiteboard or spec document. I wasn't expecting that to be controversial.
This stuff is difficult - if I remember correctly the original web components vision was a completely self-contained package of everything - that didn't survive contact with reality - however the things like custom-elements, templating and ES modules are, in my view at least, very useful - and I'd argue they are also the things that had the most precedents - because they were solving real world problems.
That is an irrational comparison. There is no comparison between components and something imaginary or theoretical. The comparison is between components and not imposing components into the standards, which are both well known conditions.
People don't need components. They want components because that is the convention familiar to them. This is how JavaScript got classes. Everybody knew it is a really bad idea to put that into the standards and that classes blow out complexity, but the noise was loud enough that they made it in for no utility reason.
> People don't need components.
The idea that people don't want some sort of improved modularity, encapsulation, reusability, interop etc I think is wrong.
We can argue about whether components as proposed was the right solution, but are you arguing that templates, custom elements and modules have no utility?
Templating, for example, has been implemented in one form or another countless times - the idea that people don't need that seems odd.
Same goes for a js module system, same goes for hiding markup soup behind a custom element.
> The idea that people don't want some sort of improved modularity, encapsulation, reusability, interop etc I think is wrong.
And web components are an extremely shitty half-baked near-solution to any of those.
Still not sure what you are attacking - is it just custom-elements or does that include js modules etc?
We're in the discussion under an article about web components. So, web components. Which I literally explicitly called out in my comment.
Hmm...
So what do you think web components are then?
There was an initial proposal called web components that comprised a whole slew of enabling technologies - like custom elements, like modules, templates etc. Some of the proposals never got implemented.
The closest single thing to web components is custom-elements ( with optional shadow dom and optional slots ).
So is that what you are objecting to?
That completely misses the point. You are mistaking your preference for some objective, though unmeasured, benefit.
I could understand an argument from ignorance fallacy wherein your preference is superior to every other alternative because any alternative is unknown to you. But instead, you are saying there is only way one of doing things, components/modularity/templates, and this is the best of that one way's variations, which is just a straw man.
You really aren't limited to doing this work the React way, or any framework way. If you want to continue doing it the React way then just continue to use React, which continues to evolve its own flavor.
> But instead, you are saying there is only way one of doing things,
Nope. I did not say there is only one way of doing things. I asked you whether you really thought people didn't want improved modularity, encapsulation, reusability, interop.
For example without standardised modules you either had to choose one of several community module systems or live with poor modularity and encapsulation. And by standardising modules interop improves.
> If you want to continue doing it the React way then just continue to use React,
Only one of us is appearing to want to stop the way the other only likes to develop. If I want to use custom elements why all the anger?
You can interoperate between frameworks the same way you interoperate between web components-- with events and attributes.
> agree that the original 4 parts of the web component spec ( custom elements, shadow dom, templates, modules ) had varying levels of battle testing
What battle testing? Literally nothing in Web Components was ever battle-tested before release. You wouldn't need 20+ specs to paper over the holes in the design had they actually veen battle-tested.
Read my comment again. I literally said that various parts had various levels of precedents - and that the more successful parts were those with stronger precedents.
> Literally nothing in Web Components was ever battle-tested before release.
So you don't thing the ideas of modules or templates had had multiple precedents?
Totally agree that some aspects had much less precedent - and that's why, in the end, they either didn't get implemented or haven't got much traction.
Web components are just a way for developers to build their own HTML elements. They're only a "framework" in as much as the browser is already a framework that wires together the built-in HTML elements.
I don't see any reason to lock away the ability to make nodes that participate in the DOM tree to built-in components only. Every other GUI framework in the world allows developers to make their own nodes, why shouldn't the web?
> too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex.
Do you have any concrete examples there? What "mechanics" are you referring to. Given that very complex apps like Photoshop, Reddit, The Internet Archive, YouTube, The Microsoft App Store, Home Assistant, etc., are built with web components, that would make the claim that they're unusable seem silly.
With your other specific complaints about the community, I think I can guess you are. That person come into our discord server, was so mean and rude to everyone that they had to be told by multiple people to chill out. Had one very specific proposal that when multiple people thought it was a bad idea, threw a fit and said we never listen. You can't just come into a place and behave badly and then blame the community for rejecting you.
> Do you have any concrete examples there? What "mechanics" are you referring to
Try the 2022 Web Components Group Report. Including things like "most these issues come from Shadow DOM".
> Given that very complex apps like Photoshop, Reddit, The Internet Archive, YouTube, The Microsoft App Store, Home Assistant, etc., are built with web components, that would make the claim that they're unusable seem silly.
Trillion dollar corporations also build sites in Angular, or React, or Blazor, or...
So you're saying that the web components community ignores the issues with web components by... writing a report on the issues with web components?
I still don't know what "mechanics and assumptions" are baked according to the OP.
So you're deflecting from the original point raised.
Anyway, yes. Web Component "community" was fully and willfully ignoring most issues that people (especially framework authors) were talking about for years.
At one point they managed to produce a single report (very suspiciously close to what people like Rich Harris had been talking about since at least three years prior for which he got nothing but vile and bile from main people in the "community"), and then it went nowhere.
> I still don't know what "mechanics and assumptions" are baked according to the OP.
Again: you do, people who wrote the report do, but you all keep pretending that all is sunshine and unicorns in the web component land.
While the report very explicitly calls out a very major behaviour baked in, for example. And calls out a bunch of other issues with behaviours and mechanics. While web components need 20+ specs to barely fix just some of the assumptions and baked in mechanics (that literally nothing else needs, and most of which exist only due to web components themselves).
Anyway, I know you will keep pretending and deflecting, so I stop my participation in this thread.
Adieu.
We have been using the isolation stuff in Web Components to make React applications that our partners can embed in web pages regardless of what other CSS and JS they use. I don’t know if I’d want to make an application with 100 tiny web components at the level of individual buttons and such that work together but self-contained widgets that pop into a web page look great to me.
We basically tried wrapping an entire registration app into the Shadow DOM just for a hopeful kick but it came with weird accessibility quirks, arrow keys not always working to go through selections, and some overlays acting strangely. We were using Shadcn which is powered by Radix Primitives, however, and a setup they probably weren't expecting or testing their code to be in.
But for smaller things like chat widgets or players I think it's a great solution.
We had overlay problems with a fancy <Select> control, also systems like Emotion can have trouble, or anything that is portalized or computes coordinates for absolute positioning. We were able to fix all the ones that affected us.
Funny we have been using the HTML <dialog> because you can't really pass accessibility reviews if you use the modal dialogs that come with MUI, Reactstrap, etc. Only <dialog> really inerts the whole page but you run into very similar problems getting components to work properly inside them which we were able to solve for all the components we use inside dialogs, but I think it's an absolute shame that this has not been adopted by MUI or anything I can find in npm -- what I hate about accessibility is that I feel like I'm held accountable and my organization is held accountable but not the people who write trash specs, make trash screen readers that crash my computer, vendors of React components, etc.
Wow, this is a weird a comment. Who are "they"? You sound like you think there's some giant conspiracy against JS frameworks. Is the Illuminati behind this? I kid, but a browser feature is kind of what it is. It can take years for features to make it into enough browsers to make them usable. It's quite a bit different than the fluidness of a JS framework.
This discussion comes up all the time and I always have the same response: not everyone needs a full-on framework for what they're doing. They also may need to share that code with other teams using other frameworks or even third parties. The post even mentions that web components may not be a good fit for you.
> Who are "they"? You sound like you think there's some giant conspiracy against JS frameworks.
Yes. There is. The main developers and proselityzers were completely insanely biased against web frameworks (especially React).
It wasn't even a conspiracy. All you had to do was to follow Alex Russel (the person who introduced the idea of web components in the first place) and see his interactions with framework authors and his views towards web frameworks.
The new people in the space driving the specs are hardly any better. E.g. their reactions to Ryan Carniato's rather mild criticism of Web Components is just filled with vile, bile, and hate.
They literally refuse to even admit they have a problem, or want to look at any other solutions than the ones they cook up.
> but a browser feature is kind of what it is. It can take years for features to make it into enough browsers to make them usable.
Strange, browsers push dozens of specs for web components without ever taking any time to see if the yet another half-baked "solution" is actually workable.
Some links to examples of the sort of behaviour you're describing would be really helpful here (I say this as someone who is sympathetic - I work with on a web component/Lit codebase in my 9-5 and I'm not a fan, compared to the React workflow I had in a past life).
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: https://toot.cafe/@slightlyoff/113222280712758802
This is the article he's reacting to: https://dev.to/ryansolid/web-components-are-not-the-future-4...
---
Or here's Lou Verou (a TAG member) calling it hate (this is the mildest reaction, btw): https://x.com/LeaVerou/status/1840134654852247765 and uncritically reposting a bullshit article calling it excellent https://x.com/LeaVerou/status/1839736908370587947 (see reaction by Vue author: https://x.com/youyuxi/status/1839833110164504691 and https://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: https://lea.verou.me/blog/2024/wcs-vs-frameworks/
Here's Rich Harris (author of Svelte) in 2019: https://x.com/Rich_Harris/status/1198332398561353728
Here's the 2022 Web Components Group report: https://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.
Its not a conspiracy. It is just group behavior following a trend as loudly as possible.
Web components are a trend? I've been using them for close to 10 years and they're still not anywhere close to mainstream. Loudly as possible? They've quietly just kind of been there for years.
I think we have a generation of developers that only know React and they're so engrained with it they simply cannot imagine a world without it. If you really can't find a use case for web components then you're living in a bubble.
We have been through all this before with jQuery. The generation of JavaScript developers at the beginning on React only knew jQuery and they really wanted to shoehorn all the jQuery nonsense into the standards. From their perspective it makes complete sense because that is the only one way to do things. They got querySelectors into the DOM.
Now we are seeing the exact same thing again. People only know React, so they want the standards to look like the only one thing they know. That doesn't make it a good idea. Every time this comes up we exchange simplicity and performance for easiness and temporary emotional comfort. Its only a temporary win until the next generational trend comes along.
> If you really can't find a use case for web components then you're living in a bubble.
There's a very tiny use-case for web components. And even there it's riddled with a huge amount of potential (and actual) footguns that "in the bubble" devs have been talking about for a decade at this point, and some which were finally acknowledged: https://w3c.github.io/webcomponents-cg/2022.html (no updates since)
> There's a very tiny use-case for web components.
That's weird, we've been using them at my company for a number of years and there's plenty of other examples of them being adopted elsewhere too. This continues to read as, "it's not React, so it's bad."
There are companies that still use jQuery, or Angular, or Ember, or vanilla JS, or Blazor, or...
Just because tech exists and is usable doesn't mean it doesn't have a list of issues and footguns a mile long, some of which are explicitly recognized by the Web Components Working Group. And which still need 20+ various specs to paper over.
Agree. web components are not a 1 to 1 replacement for a component based framework. There was a lot of promise but the implementation is lacking.
> Web Components have too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex.
Does not line up with my experience (the past 8 years or so of working with native web components, Polymr and the Lit library) at all. You can build staggeringly complex views using nothing but web components, I’ve done it, I am doing it, and inshallah I will keep doing it.
What in particular do you believe web components are unusable for? What do you count as crossing the line into ‘slight complexity?’
Yes Microsoft DHTML and behaviors were this and represented tremendous lock-in. Plus, they were terrible. Those who don’t know their history are truly doomed to repeat it.