> I [...] think it's more likely that some part of the Web Components tech stack will be removed from Chrome, Safari, and Firefox in the next 20 years, consequently breaking apps built with them, than JavaScript will change in a way that means a React 16 app I wrote 2 years ago will break.

Hmm. I think you've specified a bet you are likely to win, but one that's nearly meaningless. Perhaps if you fully lock down all dependency versions your React 16 app will not break, but that's a little more like running an old program in a VM or an emulator than "I can still work and hack on my React 16 app."

A more meaningful bet would be, "can you still develop on a React ZZZ app vs. can you still develop on an app built with web components."

If I got to pick the terms of the bet (to favor my viewpoint XD but also to make it more meaningful), they'd be "would updating a React app to catch up on N years of dependency updates be more or less effort than updating a web-components built app to catch up on N years of dependency updates"; if you keep your web-components built app from having a bunch of weird dependencies, I think the odds are very much in favor of the React app taking more effort to update.

Basically, betting on browser vendors to be less likely to break backwards compatibility than the authors of React.

> I honestly think it's more likely that some part of the Web Components tech stack will be removed from Chrome, Safari, and Firefox in the next 20 years, consequently breaking apps built with them

That already happened.

HTML Imports got deprecated (in favor of a JS-only solution), though Firefox already implemented them.

Custom Elements v0 was deprecated even though Chrome implemented it and hastily re-wrote Youtube with it. They had to wait ~4 years to remove the implementation because it took Youtube that much to switch.

The v0 part of it should mean none of that was a big surprise. It was an early prototype, it’s stable now.

v0 (IIRC) was not called v0 when it was released. It was called "custom web components". The release of a new version of custom web components is what caused the re-name to `v0`, with the new version being called `v1`. So you built on top of one version to be told later that you'd participated in a beta (unbeknownst to you).

hmm. doesn't stuff like this happen every time that chrome implements some interface but other browser vendors don't get on board with that specific version? doesn't this happen... kind of often? isn't it apparent that there's a risk of this happening whenever chrome implements something before there's standards agreement?

> doesn't stuff like this happen every time that chrome implements some interface but other browser vendors don't get on board with that specific version?

Yes. What rarely happens though is that Youtube gets immediately rewritten with the new tech.

shrug one arm of alphabet pushes through changes to Chrome without standards consensus, another arm of alphabet makes a poor bet on it.

Correct me if I'm wrong, but I think running old code and not updating the dependencies might make your site vulnerable to security vulnerabilities that get discovered over time and fixed with new versions of libraries. So if you want to keep your code secure you will need to update libraries. But those old versions of those libraries will stop being supported, and known vulnerabilities will start to accumulate that have no fix. And attackers will probably have programs scan the web for websites with known vulnerabilities and automatically attack them.

Versus if you use a library or platform (like Web Components) that cares a lot about backwards-compatibility, they will maintain the security while also supporting your old code for longer.