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.
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.
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.
Admittedly, I might not be understanding your problem well enough, so sorry in advance if I've mischaracterized the issue.
But for smaller things like chat widgets or players I think it's a great solution.
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.
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.
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.
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.
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.
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.
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.
And web components are an extremely shitty half-baked near-solution to any of those.
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.
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.
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.
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.
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)
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."
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.
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?’