I think it was two things:

1) The original web components proponents[1] there were very heavily into "vanilla" web components. Web components are low-level APIs and just don't have the ergonomics of frameworks without a library to help. For a few elements built by a few true believers, this is ok, but when you scale it out to every component in a complex app with company-wide teams you need the ergonomics and consistency-setting of a declarative and reactive API.

2) The GitHub Next team built their work in React because they required the ergonomics to move fast and they were operating independently from the production app teams. I think the first thing of theirs to be integrated was Projects, and they could probably show that their components had much better DX. Starting from the ergonomics argument, the hiring argument would take hold.

I've seen this happen a few times where web components teams believe that the whole point of them is to not have to use dependencies, hamstring themselves by not using a helper library on that principle, and then get web components as a whole replaced for a proprietary framework in search of ergonomics. If they had used an ergonomic web component helper library, they could have stuck with them.

The irony is that these transitions are usually way easier than a framework-to-framework migration because of web component's inherent interoperability. I still consider that a plus for web components: morally and pratically, technologies should be as easy as possible to migrate away from.

[1] GitHub was so into web components that they regularly sent representatives to W3C meetings to work on them, but a lot of the original team has left the company over the last 10 years.

> Web components are low-level APIs and just don't have the ergonomics of frameworks without a library to help. For a few elements built by a few true believers, this is ok, but when you scale it out to every component in a complex app with company-wide teams you need the ergonomics and consistency-setting of a declarative and reactive API.

GitHub did have their own declarative semi-reactice webcomponent framework. It's pretty nice!

https://github.github.io/catalyst/

It not at all coincidentally bears some resemblance to the (thinner, simpler) Invoker Commands API that has shipped in HTML (they share a main author):

https://open-ui.org/components/invokers.explainer/

> 2) The GitHub Next team built their work in React because they required the ergonomics to move fast and they were operating independently from the production app teams. I think the first thing of theirs to be integrated was Projects, and they could probably show that their components had much better DX. Starting from the ergonomics argument, the hiring argument would take hold.

There's also an impression from outside that the GitHub Next team also got a large amount of pressure to dogfood LLM usage, especially in new feature building.

There seems to be a visible ouroboros/snowball effect that LLMs are causing that they were trained so much on React code that's what they know best and because that's what they know best the goal should be to move things to React and React Native to take the most advantage of LLM "speed and productivity boosts".

I'm currently a pawn that feels about to be sacrificed in a cold war happening in my own day job over how much we should move towards React to make executives and shareholders happier at our "AI all the things" strategy. Sigh.