It's like the difference between TypeScript and ES6. The goals are intentionally aligned, and as the underlying platform adds support for the constructs that power TypeScript, it can continue to delegate more and more to the underlying platform.
Knockout custom elements, for example, are extremely similar to web components. As support for web components proliferates, Knockout can keep the same framework API but use web components under the covers.
I look forward to using Web Components myself, regardless of the actual method we'll end up creating them.
Just like jQuery has become "useless" in many cases, it took us a long way to where we are today. Sure we'll need to worry about SEO, etc. but Googlebot (and others, hopefully) are already quite capable of executing Javascript.
To me the Riot.js web component syntax seems very natural to write - more so than JSX. Here's an example:
React has some obvious advantages when used with TypeScript and it's new TSX support you get type safe templates with static analysis and highlighting errors on IDE. Web components are not even trying to be type safe, however they shouldn't be seen as one or another, I don't see why they both couldn't live side by side. Who knows maybe React may merge with web components in future?
As I understand, the mental models are different enough that it wouldn't make much sense to merge them. You could certainly bundle a React app as a Web Component, but React components only make sense as React components. Because React treats the DOM as effectively write-only and optimizes for performance, I doubt the React core team would ever want to change the internals to make use of Web Components.
If web components are finalized and ubiquitous, how does that effect react?