Facebook just updated its relationship status with Web Components
mux.com
mux.com
In terms of building a web app where you control the environment end-to-end, I don't think there's any inherent upside to using Web Components over React.
You nailed it that we are shipping SDKs with visual components (like a video player) that need to be compatible across all kinds of frontends.
Instead of N number of SDKs to maintain where N is every front end framework, we have 2: a web component, and a React wrapper around the web component. Maybe in the (near) future we only have to maintain 1.
The upside is that web components will last longer than react components.
There was a great blog post about this very thing and why someone chose them over react components in their use case (making their code migration-proof across updates and stack changes): https://jakelazaroff.com/words/web-components-will-outlive-y...
How much are you betting? React components have been around longer and are more widely established, so personally I'd expect them to last longer.
If you're prepared to put money down on it, I'd wager $500USD on longbets that Web Components will still function in 20 years.
And I'd wager another $500USD on longbets that it will be easier to port a web component written in 2024 into a new project written in 2044 than it will be to port a react component written in 2024 into a new project written in 2044.
The reason why I'm so confident is that Web Components are already a standard.
As someone who has been doing GUI development since 16-bit Windows, it's really remarkable to me how much staying power React has. It's 10 years old and still the dominant way of building web applications. I can't think of any other frontend library (web or native) that has had that long of a run at the head of the pack.
What I'd be most concerned about with any 20-year bet is what new paradigm/library might come along and supplant the old ways. Standard or not, React has a critical mass that will keep it viable even if it becomes "legacy". If some new hotness makes web components look old-fashioned, the small community could disappear pretty fast - browser standard or no. Ask any XSLT developer.
Web Components are used by internally by browsers to implement elements.
As dannye stated (https://news.ycombinator.com/item?id=40292970): input, textarea and video are all web components. And since the major browsers have implemented those elements in that fashion I think it's safe to say they have most certainly reached widespread adoption. (even if most people haven't realized yet)
> I can't think of any other frontend library (web or native) that has had that long of a run at the head of the pack.
Flash and jQuery come to the front of my mind. React (or at least the React of today) will one day be looked back just as we look back at what came before it.
I think it'd probably be fair to say we're at that point about 10 years after the record-tuple proposal goes through and the explicit resource management gets a syntactic sugar upgrade a la promises to async/await. They shift the paradigm enough that the old assumptions used when building our current frameworks will need to be re-examined. New frameworks will be able to blossom, and/or the current frameworks will shift enough internally that they won't resemble how they are today, and they will have to drop support for older code, or run slower compatibility layers that no one would want to use on newer projects.
Even if one of those proposals fails to go through, we would still have other standards moving with enough momentum to eventually change the landscape. In the long term, I'm looking at a lot of capabilities being added to wasm to make compile-to-wasm look more attractive.
Flash and jQuery are contenders, but still aren't comparable. They didn't run as long at the head of the pack, and the web (and web development community) was much smaller back then. React is still going strong.
I agree with you, all things (and especially all technologies) end. But I'm not ready to speculate what the post-React world will be like. I don't think we've even seen "peak React" yet.
Altering Web Standards in such a way that may break old sites is abhorent to Web Standards bodies. (See the array.contains prototype discussion: http://esdiscuss.org/topic/having-a-non-enumerable-array-pro...)
> Flash and jQuery are contenders, but still aren't comparable.
I would contend that they are. Flash was enormous, it was installed for 92% of all internet users. (Source is wikipedia, they've rewritten the page, but it still appears in google's cache, search: "flash player 92%") It wasn't just the standard, it was the industry. Jquery too used by at least 76.9% of all websites, compared to React at 4.2% all websites. (source: https://w3techs.com/technologies/details)
> But I'm not ready to speculate what the post-React world will be like.
I am.
React is currently adding web component support right now.
TC39's tuple/record propsal will reshape dataflow in component libraries/frameworks. Eventually we will get syntactic sugar for explicit resource management to make it easier to use a defer style setup/pulldown like in other languages. Both of those (plus the decorator proposals + extensions) will change the dataflow and ergonomics of the js landscape.
Frameworks will adapt into new shapes of be supplanted.
If react wants to keep adding new ways to do things to hold onto the "react" brand then by all means, but even now it wouldn't be unfair to say we're in a post-<this kind of>-react and a post-<that kind of>-react world.
Flash and jQuery had their time in the sun, certainly, but not as long as React, and the web (and web development community) in the 2000s was tiny by modern standards. Also, I don't believe that "user installed base" is an important metric - "number of programmers deliberately writing software with it" provides the network effect.
If anything, your point about the ubiquity of Flash reinforces my point that "web standards" can change pretty suddenly when mindshare changes. The writing was on the wall, but the iPhone really killed Flash.
"Web Components now" has been the "year of the Linux Desktop" refrain of the webdev community for a long time now. It's possible (just like Linux on the desktop is), but given the history, my prior is to be skeptical. And it's possible we haven't yet seen the hit product (eg iPhone) that reshuffles the technological landscape.
Do I think WCs will disappear anytime soon? Certainly not. Do I think it might end up being part of plumbing underneath frameworks like React that nobody thinks or cares about? Possibly. On a 20-year time scale, will web technologies as a whole be disrupted? Possibly.
WebSQL never became a web standard because it never had a specification so that doesn't compare properly with Web Components. XHTML on the other hand does, and it's still supported. In terms of the wager, if Web Components goes the way of XHTML then I would still win that wager.
> Flash [...] 2000s was tiny by modern standards [...] I don't believe that "user installed base" is an important metric - "number of programmers deliberately writing software with it" provides the network effect.
Well there's two things here.
1. It's important to remember to focus on percentages rather than numbers because the total developers and users have changed. If we weren't looking at the percentages then we would end up with a skewed perception. (and since there were millions of web developers back then, we won't need to worry about sample size jitter/bias)
2. I agree that user installed base is not as useful a metric as a developer use base. So looking at flash's usage, it was 3 in 10 web developers (30%) compared to React's 1 in 4 web developers (25%). (fun aside: flash was used in at least 70% of games, 75% of video delivery methods and 98% of enterprise apps so for a bunch of areas it dominated)
> jQuery
I'm guessing I don't need to go through how this was used to make a standard working environment that standards bodies then recreated.
> "Web Components now" has been the "year of the Linux Desktop" refrain of the webdev community for a long time now.
No, just among clickbaiters. Web Components was a set of capabilities/standards wrapped up under an umbrella term. Here's a map of them: https://postimg.cc/87Ljbhdj
Web Components cannot currently replace React as a whole since not all of the standards are implemented yet. (the speed of implementation is partially due to browsers needing to change a lot of behind-the-scenes functionality to support them, but a lot of that work is done now leading to browser vendors porting existing functionality to web components)
However, a whole bunch of those standards are currently implemented meaning that depending on your use-case, Web Components are the best choice. (They're doing really well in enterprise right now, e.g. Google, Microsoft, Adobe, Salesforce, etc...)
We won't have a "year of", but as each standard on the umbrella becomes available we get a "this group of devs who needed this one thing" and a "that group of devs who needed just one thing" moving to web components.
and that's why it's going to fail.
you cannot do something based on progressive enhancement and not repeat tons of html with web components.
but i guess that's why we have noscript tag. /shrugs
(My reason is that I've seen standards come and go and have found e.g. old files easier to open when they're in nonstandard-but-popular-in-the-past formats than when they're in a standard format that didn't see wide adoption.)
I guess the second bet's criteria would depend on both the recommended practice for moving components today and the recommended practice in the future (which we don't know yet so it'd have to be done in good faith).
Currently, web components are designed to be portable so they can easily be ported between projects by copy-pasting a single hunk of code.
Whereas react components can be copy-pasted, but (as far as standard practice is concerned) require build systems and their dependencies (both of which rot over time) before they can be considered functional.
Aside: There's an argument to be made about the difficulty of migrating some web component based design systems (due to build systems and dependencies), but those difficulties that would be experienced are locked into the design system itself and would be experienced regardless of whether the design system was implemented with web components, react, vue, svelte, angular, lit etc... The bet is about an individual component and how easy it would be to port.
-----------------------------------
To respond to your reasoning, I feel that it's important to point out there is a difference between standards and web standards.
The pendulum of standards themselves may come and go, but web standards almost entirely swing towards the coming side. The going side is reserved almost entirely for newer standards that subsume older web standards so the older web standards are still supported.
Anyone can make a standard, but a web standard proposal doesn't become a web standard until it has become adopted and implemented. This means that web standard proposals can be thrown away without affecting web standards themselves.
It takes a black swan event to remove a web standard (e.g. spectre/meltdown leading to SharedArrayBuffer's removal).
When it comes to web standards, backwards compatibility is sacrosanct.
Consider this simple ES1 example code:
-----------------------------------
var person = {
name: "John",
age: 30,
sayHello: function() {
console.log("Hello, my name is " + this.name + ".");
}
console.log(person.name); // Output: "John"
person.sayHello(); // Output: "Hello, my name is John."
-----------------------------------
It still works.
Now try to picture this functionality implemented in "nonstandard-but-popular-in-the-past formats" like java applet, flash file, coffeescript and an old jquery plugin.
Would that code be more straight forward to make functional today than the web standard ES1 code above?
Now that question above doesn't neatly fit with your reasoning because you were comparing "nonstandard-but-popular-in-the-past formats" with "a standard format that didn't see wide adoption". I think we can both agree that ES4 was something that fit into the second bucket. And judging by your comments I think you would say that Web Components as they exist now would also fall into that second bucket.
But I would counter that with:
1. Web components already have wide adoption even if a lot of people aren't aware about it. (see comment: https://news.ycombinator.com/item?id=40295978)
2. Backwards compatibility is sacrosanct.
I'm not up for a charity thing - if we're betting I want to be able to win as well as lose - but if there's a way to do it then I'm down.
> I guess the second bet's criteria would depend on both the recommended practice for moving components today and the recommended practice in the future (which we don't know yet so it'd have to be done in good faith).
Right, yeah, happy to just say we look at it in good faith and reach a conclusion.
> Currently, web components are designed to be portable so they can easily be ported between projects by copy-pasting a single hunk of code.
> Whereas react components can be copy-pasted, but (as far as standard practice is concerned) require build systems and their dependencies (both of which rot over time) before they can be considered functional.
I don't think that's a huge difference; copy-pasting your dependency declarations and your implementation is not conceptually any harder than copy-pasting just your implementation. If the accepted dependency format changes, or your component needs custom build steps, then that might be a harder piece of porting (but I wouldn't consider a simple mechanical change like changing dependency notation from JSON to XML to be a significant burden).
And the WHATWG (for now) is "by invitation only"... note the big name missing.
Browser Vendors have been using Web Component technology for INPUT, TEXTAREA, VIDEO and the like, for many many many moons now.
You've already lost that bet. WebComponents v0 was not only introduced and implemented, but Google rewrote Youtube with it.
It got promptly deprecated, replaced with v1, and v0 lingered for another four years before Google rewrote Youtube with v1
Also to add some more specificity to the bet, I mentioned a web component created in 2024 which wouldn't be v0.
Indexed for inflation?;)
What does it mean to "last longer" when it comes to your own codebase? And why would web components help with that?
...which is the point the parent comment was making.
is the crux for me. When I clone one of my Vue projects from a few years ago and try to run it, it is always broken. My (new) node version is incompatible with a Vue core library, then updating the core library breaks some other libraries and requires config file changes.
I store dependencies in-repo whenever I can get away with it; it eliminates whole classes of devops/CI issues.
Yes, I'm being hyperbolic. But if you're worried about longevity I would certainly hitch my wagon to React before I hitched it to WebComponents.
Even if Web Components solve the “create a component” part of React there’s still an absolute ton of stuff it provides that Web Components don’t. I tend to think of WC as a low level API you want a library interfacing with rather than your own code, e.g. the way Svelte exports web components.
What about using web components in a server rendered application without needing to resort to running JavaScript in the server?
In my opinion, fundamental problems like these really ought to be addressed before things become part of the web platform.
Web Components trace their history to trying to explain how the web platform itself works. HTML is also a flat namespace, and the goal was to empower developers to do all the same things the platform does and in the same way.
We hotly debated namespaces when designing the API and in the end decided to omit them but require at least one dash. You can think of the prefix kind of like the namespace in that sense. And in practice with reasonable prefixing practices we find folks rarely (if ever) collide, the same as ObjC.
(Not that things couldn't be better: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...)
But then, all languages since Objective-C seem to agree that namespacing is a good idea. There's no debate there. Even JavaScript has modules now. So I can't help but wonder what makes web components unique in this regard.
(Yeah I work with XML day to day, yeah I might have some amount of Stockholm Syndrome associated with that.)
Ah. I feel like the demos and examples that I've seen never have the first word as the pseudo-namespace so I had no idea that was the intention.
Fundamental enough to be included in the list of things to still fix for web components: https://w3c.github.io/webcomponents-cg/2022.html#scoped-elem...
Simple as that.
The problem with web components is that they've never had a templating/reactivity story, which means if you wanted to build one reactively you'd have to ship it with a framework, and shipping a separate framework per-component is just unworkable. So they don't make sense internally to an app, and they don't really make sense for a large library of components. They only really make sense for a single hand-crafted widget that a company wants to ship to various consumers who may be using different frameworks
My dream is still that browsers come up with an actual reactive-templating API for HTML. If they did that, we might finally be able to get rid of frameworks for many common use-cases
The worrying: we might be setting up for a scenario where newer developers are bewildered by mixed paradigms within what was (at least once upon a time) a simple library
Full disclosure I work for Mux (OP), so as a team we're web component fans, but I'm personally still almost exclusively writing React. So...personally, saying this with love, but add this to all the new esoteric hooks in React 19 and it feels like React might be losing the plot.
Which standards?
I keep saying: even web components people finally admitted that they need 20 more standards to solve issues (largely caused by web components themselves) that literally no other framework has: https://w3c.github.io/webcomponents-cg/2022.html
There's a reason very few frameworks (including the new ones) target web components by default and do their own thing. And their authors have been very clear as to why (think Svelte, Vue, Solid etc.).
They are not ignored. They just don't exist or, indeed, are solved by other, better means (or indeed better web specs like CSS scoping etc.). Let me quote directly from the doc:
--- start quote ---
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
--- start quote ---
To put simply, "many of these problems exist only because web components exist, and they are so bad that developers actively avoid web components and seek other solutions".
Here is a list of issues that literally don't exist anywhere except web components (so there's nothing to ignore):
- Composed Selection
"Since existing Selection APIs can represent only a single selection in a document, bound to a single Range, the need for an API to represent ranges over a composed tree has been generally acknowledged since at least 2015."
- Constructable Stylesheets & adoptedStyleSheets
The only way for web components can share stylesheets without duplicating them
- Cross-root ARIA
"Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM."
- CSS Properties and values inside shadow root
- Anything related to declarative templates: Declarative CSS Modules, Declarative Custom Elements, Declarative Shadow DOM
- DOM Parts
"Enable batched updates to the DOM, usable by library/framework view engines."
This is actually useful. Why the hell it's tied to Web Components? No one knows. But yeah, all/most frameworks have a solution to this, and web components are useless as a foundation for web frameworks without it
- Form-Associated Custom Elements
Yup, you still can't make a custom button that behaves like a submit button in web components
- Lazy custom element definitions
Web components are eagerly rendered whether you want it or not. I don't think there's a single framework that doesn't have lazy loading/rendering/rendering on demand
- Open styling of shadow roots
- Styling children of slotted content
- Theming
https://webkit.org/blog/13711/elementinternals-and-form-asso...
I think you're looking for internals.form.requestSubmit()
(For reference, here's a long discussion in an issue: https://github.com/WICG/webcomponents/issues/814)
So is react losing the plot or just naturally it's ideas are being folded into the browser natively?
All I really wanted was just `useState()` but for a piece of state that can be shared between components. I think that exists now in easy-to-use libraries like jotai and zustand, but it certainly took a while to get there. In retrospect I don't think this is that uncommon (overcomplicating something at first and then just simplifying it to the few core things people want) - graybeards like me may remember some of the original EJB horrors.
All of this has “just worked” with React since it very first release.
Web Components are great for distributing components. Not for building the internals of an app. In fact, for moderately complex web components it often pays to build the internals of the web component with a framework like React or Svelte.
Make a Llama 3 based search as the home page :) And fully support AI/LLMs in the browser :)
Say you have a component library where each component depends on a base set of styles and you don't want to load duplicate styles for each component.
Is there a best practice around this yet?
https://lit.dev/docs/components/styles/#inheriting-styles-fr...
https://lit.dev/docs/components/styles/#sharing-styles
Already quite some time ago I made a little library which makes this easy:
They have proposed it. They have also explained why the existing proposal for customisable built ins is a loaded gun waiting to explode.
> To date they have done neither
Tell me you know nothing about the topic without telling me that
That is laughable. I've been following this since finding that my code extending built-in elements for progressive enhancement in the Hotwire framework was dead in the water on Safari and no polyfill could resuscitate it because the browser infrastructure was fundamentally missing. In reality, Apple have sat on the pot groaning for a decade without taking a dump, and the stated reason in 2016 was this, entirely:
rniwa> The problem here is that UA internally checks local name e.g. `element.localName == aTag` to do various things, and all of that code needs to be updated to account for the fact there could be an instance of `HTMLAnchorElement` whose local name is not `a`.
rniwa> The position has been established.
[WebKit locked as off-topic]
So it's fundamentally an effort-reward gap for Apple that has become a dug-in entrenched position over time as more product managers flail around hoping to justify it. Pretending an obviously commercial/resourcing decision is due to <bunch of technical reasons> is a common way to avoid committing resources, but any engineer who actually believes that fiction is a damn fool. I'm reminded of Cisco's hissy fit with the IEEE over PoE. Apple aren't dumb enough to miss that refusing to implement part of a published standard erodes their claim of stewardship over that standard, and if a major customer really wanted it, they'd flip-flip in a heartbeat.
> Tell me you know nothing about the topic without telling me that
Aw, you're gonna hurt my feelings.
Its not.
> and the stated reason in 2016 was this, entirely:
It's not the entirety of the reason
> Which I took to mean, "all of you whinging bastards can get fucked, it's our browser"
Since you keep completely misrepresenting and lying about Webkit's position, sure.
I honestly couldn't care about your vitriol in the rest of your message, or any other messages.
Adieu.
Technically you can just export a string with the name of your web component:
export const MyButton = 'my-button'
import MyButton from './MyButton'
...
return <MyButton />
In my 13 years there are a lot of technologies I've never used. Maybe there was opportunities where you could have, or maybe things are working just fine for the problems you're solving and you don't need it, which is fine too.
So a new way of dealing with certain problems is required, which requires a mindset change. For most developers it doesn't add value right away to break out of their framework cage and share their components with each other. But eventually we will all benefit from web components because they will work in any environment without them ever breaking. You won't be able to say that about traditional framework components.
It's not a new way (components is not a new idea), and no, it doesn't require a mindset change (again, components are not a new idea).
Web Components have so many issues that they are nearly useless to frameworks, and Shadow DOM is the cause of many of those issues.
> For most developers it doesn't add value right away to break out of their framework cage and share their components with each other.
Ability to share components has nothing to do with suitability of web components for frameworks/libs.
> But eventually we will all benefit from web components because they will work in any environment without them ever breaking.
Except they are breaking a11y, selections, forms; they can't be lazily rendered; they cause waterfall HTTP requests; they...
Well, they literally need 20 more web standards (on top of a dozen or so existing ones) to fix issues that no frameworks have, and many of which exist only because of web components themselves: https://w3c.github.io/webcomponents-cg/2022.html
The only useful web spec that may come out of this slow moving train wreck is DOM Parts which enables batched updates to the DOM. And even then it depends on how blind the spec authors are to the actual needs of developers. And up until 2022 they weren't just blind, they were intentionally and militantly blind.
But at the same time I also feel like we should be engaged in a positive way with making certain patterns more integrated with the browser, so that the web basically becomes more native. And that can be implemented as a new possibility alongside the common frameworks. And those frameworks can even adapt to it.
You seem to know a lot about and be very engaged with this subject. Maybe instead of breaking it down you could help make it better? I'm personally not involved with the web component development, but I find their ideas interesting and worthwhile exploring. Web standards evolve slow but stay long. It's good to know what's coming.
Yes, I am, hence the arguments.
I'm not the only one against them. There are multiple reasons why even the people who originally modeled their frameworks after web components and were very pro-web components are not at best completely indifferent towards them: Svelte, Vue, Solid JS.
> I understand you're issues with it, but I also think that implementing web standards is a different thing from a framework
Yes, yes, it is a very different thing, and that's why you should be very careful when implementing anything, and listen to people who have to deal with these standards.
People working on these standards would ignore, berate, denigrate and gaslight anyone who would point out glaring and obvious issues with the design of web components. They would throw more and more standards at the problem trying to patch holes that were caused by the design of web components.
In 2022 they finally relented, sat down and wrote what more is needed to bring web components barely on par with existing userland solutions. And admitted that many of the issues that still need to be solved are the direct result of their design.
> But at the same time I also feel like we should be engaged in a positive way with making certain patterns more integrated with the browser
People have tried to do that. As I say, they were ignored, belittled and gaslighted. The people who were the most vocal proponents are now at best indifferent and will not touch web components with a 10-mile stick.
Anecdotally it feels like they arrived right as headless/self-styled component libraries started to pick up steam, and things inverted to the point that not being able to have your "external" styles easily apply to the component became more of a problem than them being affected by random stray styles.
I wonder if that is the true reason OLE type systems have failed on the web, as there aren’t enough agreed upon preexisting widgets for it not to descend into an inconsistent horror show.
This is the inherent tension. It requires good web component authoring to expose:
1. `part`s that can be accessed by application-level CSS
2. slots for the application developer to inject html
3. CSS custom properties (--variable) -- these pierce the shadow DOM
The web component authors have to be very intentional about these things. There are good examples and bad examples and I think people are still learning how to do this well.
It is almost like the need for styling necessitates all the old dependency injection and factory gunk that older frameworks became notorious for.
.login-form { --button-outline-width: 2px; }
.credit-card-form { --button-outline-width: 2px; }
Of course, the component needs to be authored & documented in a way that supports this.
For example, shoelace has a "Drawer" component: https://shoelace.style/components/drawer
By default the drawer component has an "X" button in the header to close it. If you want to override that, instead of trying to style the nested "X" button you can pass in your own header actions with slot="header-actions"
In practice, this update is great for usability. But it's a sign that web components are still relevant, extending my time dealing with poorly built ones.
More broadly speaking I have found myself getting thrashed by the ever evolving "best practices" in the React ecosystem. First: write everything using class components, and then a couple years later everything should be written with hooks.
I think the benefit of web components (for certain things) is that the APIs and the standards move slowly. Something you write today isn't going to feel obsolete in only a couple years.
If you need an equivalent Expedient Field Hack for a web component, remember it's an HTMLElement subclass and ends up in the DOM. So you can get the object back out of the DOM as 'just another internal element' and gutwrench it from there (or, depending, subclass it and register your subclass, or insert an extra entry into its prototype chain, or ...).
I mean, yes, those are all horrible, but so's digging into the guts of a react component you don't own, sometimes taking a dependency on the internals of somebody else's code is the least horrible option.
... it occurs to me that given a JS Function's .toString() returns the source code, on an e.g. lit-html component you could probably even grab the render function, yank the html`...` call out of it, regexp that to tweak the mark up, and then use an indirect eval to stuff it back in.
But really, I think "you now have the element object, monkey patch it to taste" is probably quite sufficient and far, far less ridiculous than that last paragraph, I just couldn't resist sharing the horrifying thought :)
Yes, ad-hoc fixing styles and behavior from the outside is nice. But when every internal style/class/element is technically part of the API surface, you quickly end up with extremely brittle code.
Suddenly every tiny change (bug fixes, refactors, new feature) in the component library has the potential to break the app in unexpected ways, and the result is an inability to upgrade. Happens all the time.
With shadow DOM, this problem basically go away (depending on how it’s implemented)
Such as what?
The only issue with web components is shadow dom makes styling a pain so you need to work without the shadow dom and implement slots yourself.
Personally I wouldn't mind server rendered features like what react does but in the setting of not javascript.