Your comparison is like comparing The Eagles to some little local rock band!
Rather than two competitive products I think React and Kube are both market dominant products that reveal the engineering culture, values and impact of the two organizations.
I can say that when I first started with React I thought it sucked and looked at Vue and Svelte and similar things. My take on all of them was that they made the internal frameworks I was using to build very complex RIAs in the 2005-2010 time frame look like something that fell off a UFO.
I first thought Vue reflected the way I thought about conventional "webby" applications particularly in terms of treating lists as a first-class object. I eventually learned with React how to draw absolutely anything, even whole 3-d worlds!
I guess what I'll say about Svelte is "if you make such a radical change in your framework did you really believe in it?" Early on I stuck to controlled forms in React because uncontrolled forms seemed structurally unstable (add one too many features and it all breaks) and then I discovered
which is easy and very high performing. What I really like about React is not so much the DX or UX but rather the way it uses functions to seemingly transform a language into something else in a conceptually simple way... And how it solves the problem of composing components written by different people and organizations to the extent that we've now got the terrible problem of managing an app that has 50 third party components and 5 CSS management frameworks.
But Kubernetes is solving a much messier and more complicated problem than React. There are numerous similar web frameworks to React in different languages that have been created as basically hobby projects.
Of course Kubernetes is going to be way less fun to use. The problem of managing servers and distributed applications at scale is inherently not fun once you get into the nitty gritty details.
Kubernetes has the basic flaw that it has more scalability than 99.99% of companies need and you could serve almost all the market with a system that supports shared data structures (like IBM's Sysplex) and is more opinionated. An architecture which is less scalable could serve almost all of the systems on the planet and would be easier to work with.
I'll grant that there is essential complexity there, but Kube was built by people who didn't have fear of accidental complexity so it has a lot of it. Look at the whole "YAML sucks" thing which is partially a YAML thing (coulda chose something different) and also a function of the system they are trying to configure with YAML.
Kubernetes' YAML problem stems from its CLI tooling, and yes it was an atrocious choice once templating came in and visited horrors like helm on us. Internally, the the k8s api speaks only JSON, and you can already stuff whatever json you like in a yaml file.
Rather than two competitive products I think React and Kube are both market dominant products that reveal the engineering culture, values and impact of the two organizations.
I can say that when I first started with React I thought it sucked and looked at Vue and Svelte and similar things. My take on all of them was that they made the internal frameworks I was using to build very complex RIAs in the 2005-2010 time frame look like something that fell off a UFO.
I first thought Vue reflected the way I thought about conventional "webby" applications particularly in terms of treating lists as a first-class object. I eventually learned with React how to draw absolutely anything, even whole 3-d worlds!
https://aframe.io/
I guess what I'll say about Svelte is "if you make such a radical change in your framework did you really believe in it?" Early on I stuck to controlled forms in React because uncontrolled forms seemed structurally unstable (add one too many features and it all breaks) and then I discovered
https://react-hook-form.com/
which is easy and very high performing. What I really like about React is not so much the DX or UX but rather the way it uses functions to seemingly transform a language into something else in a conceptually simple way... And how it solves the problem of composing components written by different people and organizations to the extent that we've now got the terrible problem of managing an app that has 50 third party components and 5 CSS management frameworks.