However, what's less excusable is thinking React components are somehow equivalent to XML: React components are a lot more than bits of JSX (components very often don't contain any JSX, it's an optional syntax extension, not a fundamental part).
There's very little in common between React components and the XML definitions used by Qt,
> UI with an XML syntax language
If you're interested in learning a bit about how React works, I'll start you off with this: React doesn't really do UI directly at all. It isn't layout-aware, layout is handled by the rendering target: e.g. DOM+CSS for the ReactDOM rendering lib, HTML+CSS for the ReactDOMServer rendering lib, UIKit for the RN iOS rendering lib, etc.
> I'm deeply familiar with React
I'm not trying to be snarky here but... React is not declarative.
Though it's good you highlighted that as that is essentially the fundamental difference here: WPF/QT are declarative, CSS is declarative, UIKit is (mostly?) declarative, HTML is declarative(-ish). React components aren't.
It's a far cry from an immediate mode API where you are making draw calls.
And it's not really representing UI: that's the main point here. Layout is decoupled; it's only really representing front-end logic and state.
I liked this about react, you create a render function and render your stuff. It is miles of head or the angular horrible architecture but the Web needs basic components implemented naively that developers can extend and not start every time from Zero with divs and other basic stuff.
To cut the explanation short, the former means while initial UI state was declarative (with XML), runtime mutations of UI were mostly imperative with a binding turing complete language.
The recent Component based model of composing UI - the runtime mutations of the elements are expressed as state updates inside the UI declarations itself(and declarations are usually done with a turing complete language)
is pretty much how Qt does it with QML (released in 2011), except that instead of requiring explicit function calls, the variables are themselves reactive so that:
Button { text: "foo" + counter.value }
Compos ability for me means I can make a big component by combining smaller ones, what does it mean to you?
Extensibility is the important part, you can get a DataGrid and add 10 lines of code to add some feature to it and you inherit everything from the base component, you get it all: the performance, the events, the accessibility. In web I only see shitty implementation that fail in different ways, even the YouTube search + dropdown input fails sometimes and remains open until you reload the page, a ton of Google "geniuses" can't implement a shitty component with all their languages and frameworks.
I personally like about react the functional part of it and not the JSX part, that is sugar syntax, though when doing complex stuff the functional part brke and you had no choice then get your hands dirty and find workarounds and do ugly stuff.
Most business work is still done with mice. Everybody thought fingered mobile would displace mouse-oriented UI's, but that was a bad prediction. Let's do open-source GUI's right this time. (Could QML be reworked to XML and made open-source?)
What do you mean? Qt,WPF, Flex was doing UI with an XML syntax language before React existed, some people prefered doing things by hand instead of rag and drop back then too. The "components" were named Controls or Widgets and the Web still is a inferior pile of shit because in this old tooljits when you needed say a custom DataGrid widget you extended the existing one and where in Web you start from Zero with divs,inputs and buttons.