4 ms·

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 y

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.

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.