Comment by unlog
7 days ago
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.
1 reply →
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.
8 replies →
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.
1 reply →
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).
1 reply →
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.
4 replies →
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.