6 ms·

As someone who quite likes Qt, why should I prefer this over Qt5+QML? This whole React Native thing just feels like "let's reinvent Qt but slower and much less

by PeCaN 11y ago

As someone who quite likes Qt, why should I prefer this over Qt5+QML? This whole React Native thing just feels like "let's reinvent Qt but slower and much less mature". Note: I really don't mean this in an inflammatory way; it just feels like people are rediscovering the cool stuff about Qt and reimplementing it but worse.

Sir_Cmpwn 11y ago
Have you drunk the react kool-aid for the browser yet? I have, and I was initially skeptical. Performance can be plenty fast but more importantly, your UI and your application as a whole is more testable, reliable, and easier to reason about if you use React (and importantly, the functional mindset that the React ecosystem comes with). I've made many desktop UIs without this sort of thing and they can be fiddly little bastards to get all of the interactions right, but React makes it effortless and reliable. I'd love to see React and Qt talking to each other.
- hellofunk 11y ago
  QML on Qt is also a declarative and reactive technology, it behaves very similarly to React for the browser, but for native widgets. I think that is what the question is about, and I'm curious too... how does React differ? Qt's QML automatically updates UI elements based on state changes. I use React for web programming and they seem like similar concepts, so I'd be curious for anyone to shed light on their differences. Qt falls more into the "reactive" domain, whereas, name aside, React is not a reactive tool, technically, but the use-case is similar for both, no?
  - Sir_Cmpwn 11y ago
    I would disagree with this. I haven't worked with QML, but I have worked with WPF which also supports two-way data bindings in a manner that I would guess is similar to Qt. The major difference between the approaches is that React embodies the functional approach. By describing your UI as a pure* function of your application state, you get a lot of important benefits. * https://en.wikipedia.org/wiki/Pure_function https://en.wikipedia.org/wiki/Pure_function
    - hellofunk 11y ago
      Several academic papers on functional reactive programming specifically discuss QML implementation, so I suspect a comparison to WPF is superficial. You may want to take a look at QML before dismissing it. I've seen react developers who have used QML say that the experience is very similar.
      - Sir_Cmpwn 11y ago
        That's why I included the disclaimier that I hadn't actually used QML. Thanks, I'll check it out.
- rplnt 11y ago
  FWIW I think React is horrible for web. It brings back the (bad) feel of flash web apps from over a decade ago.
  - untog 11y ago
    ...what? React isn't even a UI framework, there is no "feel" to it at all.
    - rplnt 11y ago
      "App startup". I.e. loading screen after the webpage was supposedly loaded. Same for transition between states (compared to how regular web pages behave).
      - mikewhy 11y ago
        Aren't those the same problems all SPAs face? At least with React you have the option of server rendering to remove your first issue.
      - untog 11y ago
        React is actually fairly unique among JS view libraries in allowing you to fully render the site on the server-side. If a site doesn't do this then it's a choice they have made. But at the very least this is not React-specific.
- PeCaN 11y ago
  I used React to write an in-browser REPL with live data browsing for a programming language that I was writing and it was admittedly quite nice. It's what reminded me a bit of Qt/QML actually. But that is my only experience with React. I have my fair share of Haskell experience so I get the benefits of statelessness. But I don't necessarily think it's a silver bullet for UI.
dustingetz 11y ago
TLDR is functional programming
- ihsw 11y ago
  And is more testable. And is easier to bring web devs onto desktop app development. And is faster to prototype. And is probably a better way to develop desktop apps. </kool-aid>
  - pax_americana 11y ago
    I disagree. I think QML is faster to prototype (you can export an existing PSD file to qml). Also QML's anchor-based layouts >>> flexbox.
  - deleted 11y ago
    [deleted]
- zurn 11y ago
  QML is declarative so it's really more functional than React's JS with some FP conventions.
  - daxfohl 11y ago
    This is the opposite of the case. Because QML is declarative, it forces the framework to be completely antifunctional. The view_model has to be mutable, so GUI updates are all about mutation. In React, the renderers are simply pure functions that take an immutable state input and spit out a view. No mutation, pure functionality that you can test.
    - zurn 11y ago
      I agree in practice QML apps are typically less functional than React apps, but QML-the-language (without connecting JS functions) is functional, like CSS.
      - 11y ago
daxfohl 11y ago
Qt+QML is more like Angular. You mock up templates and bind functionality to a view_model. This gets ugly when you try to do anything complex; your template has to accommodate all possibilities and eventually looks more like a huge laundry list than a template. With React you don't have a template. Every change generates a new virtual-HTML page, and then a diffing algorithm figures out the cheapest way to update your existing HTML with the changes. That makes things far simpler--your renderers are just HTML-generating functions, not some magical view-view_model thing that has its own syntax and workarounds for its limitations. UI is more testable because you can verify the actual HTML output, not just view_model state. Would love to see something similar to React on other GUI platforms as well.
- blub 11y ago
  I don't have experience with Angular, and you haven't specified whether you're talking about Qt or Angular, so I will make some clarifications. In QML one has QML components, which are JSON syntaxed files that can include other components and Javascript code. A component can be anything from a UI widget to a a camera object that can be used to take pictures, etc. QML encourages model-view programming which is a proven pattern used in the best UI frameworks on pretty much every platform. Nothing magical or limiting about it.

by PeCaN 11y ago

Sir_Cmpwn 11y ago

Have you drunk the react kool-aid for the browser yet? I have, and I was initially skeptical. Performance can be plenty fast but more importantly, your UI and your application as a whole is more testable, reliable, and easier to reason about if you use React (and importantly, the functional mindset that the React ecosystem comes with). I've made many desktop UIs without this sort of thing and they can be fiddly little bastards to get all of the interactions right, but React makes it effortless and reliable. I'd love to see React and Qt talking to each other.

hellofunk 11y ago
QML on Qt is also a declarative and reactive technology, it behaves very similarly to React for the browser, but for native widgets. I think that is what the question is about, and I'm curious too... how does React differ? Qt's QML automatically updates UI elements based on state changes. I use React for web programming and they seem like similar concepts, so I'd be curious for anyone to shed light on their differences. Qt falls more into the "reactive" domain, whereas, name aside, React is not a reactive tool, technically, but the use-case is similar for both, no?
- Sir_Cmpwn 11y ago
  I would disagree with this. I haven't worked with QML, but I have worked with WPF which also supports two-way data bindings in a manner that I would guess is similar to Qt. The major difference between the approaches is that React embodies the functional approach. By describing your UI as a pure* function of your application state, you get a lot of important benefits. * https://en.wikipedia.org/wiki/Pure_function https://en.wikipedia.org/wiki/Pure_function
  - hellofunk 11y ago
    Several academic papers on functional reactive programming specifically discuss QML implementation, so I suspect a comparison to WPF is superficial. You may want to take a look at QML before dismissing it. I've seen react developers who have used QML say that the experience is very similar.
    - Sir_Cmpwn 11y ago
      That's why I included the disclaimier that I hadn't actually used QML. Thanks, I'll check it out.
rplnt 11y ago
FWIW I think React is horrible for web. It brings back the (bad) feel of flash web apps from over a decade ago.
- untog 11y ago
  ...what? React isn't even a UI framework, there is no "feel" to it at all.
  - rplnt 11y ago
    "App startup". I.e. loading screen after the webpage was supposedly loaded. Same for transition between states (compared to how regular web pages behave).
    - mikewhy 11y ago
      Aren't those the same problems all SPAs face? At least with React you have the option of server rendering to remove your first issue.
    - untog 11y ago
      React is actually fairly unique among JS view libraries in allowing you to fully render the site on the server-side. If a site doesn't do this then it's a choice they have made. But at the very least this is not React-specific.
PeCaN 11y ago
I used React to write an in-browser REPL with live data browsing for a programming language that I was writing and it was admittedly quite nice. It's what reminded me a bit of Qt/QML actually. But that is my only experience with React. I have my fair share of Haskell experience so I get the benefits of statelessness. But I don't necessarily think it's a silver bullet for UI.

dustingetz 11y ago

TLDR is functional programming

ihsw 11y ago
And is more testable. And is easier to bring web devs onto desktop app development. And is faster to prototype. And is probably a better way to develop desktop apps. </kool-aid>
- pax_americana 11y ago
  I disagree. I think QML is faster to prototype (you can export an existing PSD file to qml). Also QML's anchor-based layouts >>> flexbox.
- deleted 11y ago
  [deleted]
zurn 11y ago
QML is declarative so it's really more functional than React's JS with some FP conventions.
- daxfohl 11y ago
  This is the opposite of the case. Because QML is declarative, it forces the framework to be completely antifunctional. The view_model has to be mutable, so GUI updates are all about mutation. In React, the renderers are simply pure functions that take an immutable state input and spit out a view. No mutation, pure functionality that you can test.
  - zurn 11y ago
    I agree in practice QML apps are typically less functional than React apps, but QML-the-language (without connecting JS functions) is functional, like CSS.
    - 11y ago

daxfohl 11y ago

Qt+QML is more like Angular. You mock up templates and bind functionality to a view_model. This gets ugly when you try to do anything complex; your template has to accommodate all possibilities and eventually looks more like a huge laundry list than a template. With React you don't have a template. Every change generates a new virtual-HTML page, and then a diffing algorithm figures out the cheapest way to update your existing HTML with the changes. That makes things far simpler--your renderers are just HTML-generating functions, not some magical view-view_model thing that has its own syntax and workarounds for its limitations. UI is more testable because you can verify the actual HTML output, not just view_model state. Would love to see something similar to React on other GUI platforms as well.

blub 11y ago
I don't have experience with Angular, and you haven't specified whether you're talking about Qt or Angular, so I will make some clarifications. In QML one has QML components, which are JSON syntaxed files that can include other components and Javascript code. A component can be anything from a UI widget to a a camera object that can be used to take pictures, etc. QML encourages model-view programming which is a proven pattern used in the best UI frameworks on pretty much every platform. Nothing magical or limiting about it.