3 ms·

-Like React/React-native ecosystem pioneered the component based declarations of UI elements. What do you mean? Qt,WPF, Flex was doing UI with an XML syntax l

-Like React/React-native ecosystem pioneered the component based declarations of UI elements. 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.

lewisjoe 4y ago
I think you are confusing XML style UI declarations with composable-components-based UI declarations. 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)
- jcelerier 4y ago
  > 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 } updates automatically whenever "value" changes. See e.g. https://www.qt.io/product/qt6/qml-book https://www.qt.io/product/qt6/qml-book (or a small TodoMVC example I did at somepoint to see some actual code: https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qml https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qm... )
- simion314 4y ago
  you think bindings are super cool like bind the hidden state of soemthing to some variable then Flex did it before React and probably was not the first. 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.
lucideer 4y ago
There's a common misconception that JSX is XML - that's very excusable as the syntax is based on XML, but it's not the case and you should look into JSX in more depth if you think it is. 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.
- HelloNurse 4y ago
  Another fun fact about React (at least React Native): there are basically two separate "engines" for class-based and function-based components, with subtle differences.
- nightski 4y ago
  I think the point was that they were declarative and retained mode systems and existed long before react. I'm deeply familiar with React and systems such as WPF/QT and I can see the comparison.
  - lucideer 4y ago
    > I think the point was that they were declarative ... > 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.
    - nightski 4y ago
      I have to disagree. You produce a data structure representing the UI. That's basically the definition of declarative. Just because you can build that dynamically doesn't mean it is not declarative. You could always build up XML dynamically as well. It's a far cry from an immediate mode API where you are making draw calls.
tabtab 4y ago
What's sorely needed is an open state-ful GUI markup language that targets CRUD and data, something HTML/DOM still sucks bigly at. We wouldn't need language binding libraries if we could issue XML to give us all the common and loved GUI idioms like tabs, drop-down menus, data grids, pop-up windows, tool-bars, combo-boxes, etc. (That HTML5 deprecated frames and iframes is a shame. Anti-Kudos to the 5'ers. Fire those b@stards!) 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?)
- simion314 4y ago
  I have no idea why browsers maker don't look at what Desktop and Mobile GUI frameworks provide and implement same functionality, like give us a ListView or GridView that is implemented to be efficient and you don't have to use pagination as a workaround.
- nyanpasu64 4y ago
  Qt has data grids built in, but QAbstractItemModel is a nightmare to implement and interface with (https://www.reddit.com/r/QtFramework/comments/rx0c8e//hrfvyzj/ https://www.reddit.com/r/QtFramework/comments/rx0c8e//hrfvyz..., https://docs.google.com/document/d/1__bldg9SwENN2d6LyiX0wwX5oKVWoUPuGsMqJqo5dPw/edit#heading=h.5z1rhvvpsya https://docs.google.com/document/d/1__bldg9SwENN2d6LyiX0wwX5...). I think some of the incidental complexity could be fixed, and the implementation could definitely be simplified by removing dragging between widgets (which requires the model's backing data store be built around adding and removing items, rather than merely reordering them), but I feel it's inherently difficult to communicate changes to data to the QAbstractItemView in the form of individual insert/delete/move operations. I haven't explored the JS world's approaches to UI diffing or lazy-loaded data grids though.

lewisjoe 4y ago

I think you are confusing XML style UI declarations with composable-components-based UI declarations. 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)

jcelerier 4y ago
> 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 } updates automatically whenever "value" changes. See e.g. https://www.qt.io/product/qt6/qml-book https://www.qt.io/product/qt6/qml-book (or a small TodoMVC example I did at somepoint to see some actual code: https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qml https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qm... )
simion314 4y ago
you think bindings are super cool like bind the hidden state of soemthing to some variable then Flex did it before React and probably was not the first. 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.

lucideer 4y ago

There's a common misconception that JSX is XML - that's very excusable as the syntax is based on XML, but it's not the case and you should look into JSX in more depth if you think it is. 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.

HelloNurse 4y ago
Another fun fact about React (at least React Native): there are basically two separate "engines" for class-based and function-based components, with subtle differences.
nightski 4y ago
I think the point was that they were declarative and retained mode systems and existed long before react. I'm deeply familiar with React and systems such as WPF/QT and I can see the comparison.
- lucideer 4y ago
  > I think the point was that they were declarative ... > 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.
  - nightski 4y ago
    I have to disagree. You produce a data structure representing the UI. That's basically the definition of declarative. Just because you can build that dynamically doesn't mean it is not declarative. You could always build up XML dynamically as well. It's a far cry from an immediate mode API where you are making draw calls.

tabtab 4y ago

What's sorely needed is an open state-ful GUI markup language that targets CRUD and data, something HTML/DOM still sucks bigly at. We wouldn't need language binding libraries if we could issue XML to give us all the common and loved GUI idioms like tabs, drop-down menus, data grids, pop-up windows, tool-bars, combo-boxes, etc. (That HTML5 deprecated frames and iframes is a shame. Anti-Kudos to the 5'ers. Fire those b@stards!) 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?)

simion314 4y ago
I have no idea why browsers maker don't look at what Desktop and Mobile GUI frameworks provide and implement same functionality, like give us a ListView or GridView that is implemented to be efficient and you don't have to use pagination as a workaround.
nyanpasu64 4y ago
Qt has data grids built in, but QAbstractItemModel is a nightmare to implement and interface with (https://www.reddit.com/r/QtFramework/comments/rx0c8e//hrfvyzj/ https://www.reddit.com/r/QtFramework/comments/rx0c8e//hrfvyz..., https://docs.google.com/document/d/1__bldg9SwENN2d6LyiX0wwX5oKVWoUPuGsMqJqo5dPw/edit#heading=h.5z1rhvvpsya https://docs.google.com/document/d/1__bldg9SwENN2d6LyiX0wwX5...). I think some of the incidental complexity could be fixed, and the implementation could definitely be simplified by removing dragging between widgets (which requires the model's backing data store be built around adding and removing items, rather than merely reordering them), but I feel it's inherently difficult to communicate changes to data to the QAbstractItemView in the form of individual insert/delete/move operations. I haven't explored the JS world's approaches to UI diffing or lazy-loaded data grids though.