It seems like Web Components are ideal for libraries shipping pre-built components, which is probably why Mux finds it compelling. From Mux's point of view, they want the highest level of compatibility with the least amount of framework lock-in. For example, they don't want to have to ship a library for React and another one for Vue and another one for bare bones JS/HTML.
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.
(author from Mux here) -- that is correct. For the stuff we build for in-house use on mux.com and dashboard.mux.com we have a components library written in 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.
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.
I am not a betting man, but I would not be so sure. The web is littered with abandoned standards, and Web Components - while by no means a failure - have not really achieved widespread adoption yet.
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.
> The web is littered with abandoned standards, and Web Components - while by no means a failure - have not really achieved widespread adoption yet.
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.
<software that is used internally in some popular software> doesn't grant network effect - after all, the team(s) that maintain the software could replace the implementation and nobody would be the wiser. The countless humans trained to write React code are harder to fix.
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.
> 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.
...and yet standards bodies do deprecate standards that fall out of use. WebSQL and XHTML come immediately to mind, I'm sure there are more. Not that I'm predicting Web Components will go that route, but - given a long enough timeline - I don't dismiss the possibility.
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.
I'm not in the US so I'm not sure longbets would work (AIUI it's set up to do some charitable-donation tax arbitrage that only works for US taxpayers and means you can only take your winnings via a US 503(c)?) but I'm up for that second bet if we can nail down the criteria a bit more.
(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'm not in the US either but I'm sure someone will know how to make it happen, even if it goes to charity or something. (no crypto though)
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.
> I'm not in the US either but I'm sure someone will know how to make it happen, even if it goes to charity or something. (no crypto though)
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).
I would go all-in.
Web Components is not (just) about technology, but about 4 companies working together on setting a standard.
Companies that used to fight in the Browser Wars now work together on the standard.
They are the WHATWG that took the role of the W3C HTML/Web workinggroup.
4 companies ... Apple, Google, Mozilla and Microsoft
And the WHATWG (for now) is "by invitation only"... note the big name missing.
They won't last longer than a react component (that's not even the claim the linked post is making); you can just use them in a different framework, if you care about that.
...which is the point the parent comment was making.
> code saved on laptops that hadn’t been turned on in a full decade. The more dependencies a website had, the more difficult it was to restore
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.
There's also the "React is the industry standard that tons of developers and companies use" vs. the "WebComponents is the 'official' standard that nearly nobody uses".
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.
Unfortunately I don’t think that comparison quite holds. jQuery is mentioned less and less because core browser APIs implemented a lot of what it does and made it unnecessary.
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.
If it's a choice between removing the JQuery dependency from old JQuery code, or updating equally old vanilla javascript, I'm going to be picking the first option a lot.
The point isn't that it's a standard, it's that it's implemented in browser (not in a framework), and is a lot closer to the web equivalent of "bare metal". There are less moving pieces that will break backwards compatibility in the next 10 years (is the hope)
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.