7 ms·

It's nice to see that the traditional desktop GUI programmers finally realize that the way the Web people do GUIs is right (React/Vue/...) and the way they did

It's nice to see that the traditional desktop GUI programmers finally realize that the way the Web people do GUIs is right (React/Vue/...) and the way they did it until now (QT/GTK/WPF/...) is wrong. Many think that the only reason people use Electron is that it's cross-platform, when that is actually a minor benefit. The big one is just how much more better and efficient React/Vue/... are at creating GUIs. I say that as someone who programmed GUIs in pretty much everything, starting with MFC.

anp 7y ago
> traditional desktop GUI programmers finally realize FWIW, I'm not a desktop GUI programmer nor am I an...uh...professional GUI programmer of any kind. Not sure exactly who is doing the realizing here, but if they are, then great!? > the way the Web people do GUIs is right There are definitely some attractive things about web frameworks' approaches, but it's important to remember that the history of "declarative UI" traces a path back through C++ imgui devtools before React happened. I see the transition here differently -- the web is so opinionated about the DOM and its rendering engine, the only thing you can iterate on to make yourself more productive is the frontmost application semantics. Full-pipeline UI toolkits have to manage changes across all the various phases of their implementations. This (I think) creates an environment where the web is a great incubator for application model experimentation. However, many projects that start on the web have a difficult time faithfully mapping to the semantics of other GUI systems (one of the driving forces behind Electron adoption IMO). This gap is one that moxie hopes to bridge -- ideally we should be able to learn from the highly productive web ecosystem while transferring those learnings further into the UI stack without the overhead and performance cliffs of typical web tools.
layoutIfNeeded 7y ago
> The big one is just how much more better and efficient React/Vue/... are at creating GUIs Efficiency is not the first thing that pops to my mind when I look at the Electron-based apps in my task manager.
- Tronno 7y ago
  They were probably referring to speed/ease of development, not application performance.
  - Gibbon1 7y ago
    > application performance I feel like this has suffered because the end users aren't the ones paying the bills in web space.
kibwen 7y ago
I'm no UI programmer, but this is such a strong claim that I would ask you to elaborate further.
eitland 7y ago
I tell you what was efficient for creating GUIs: The old Visual Basic (and I've also heard Delphi.) Doesn't mean I want them anywhere near my projects. The web is somewhat better thanks to declarative UI (for those that use it) and separation of concerns (again for those who take advantage of it).
- pjmlp 7y ago
  You can do declarative UI with Forms as well, it just takes a bit more of code than WPF to set up the data binding contexts and layouts.
fla 7y ago
I don’t think this statement is correct.For example Qt has been doing declarative with QML for years.
- hellofunk 7y ago
  I generally agree with the OP except that lumping QML into the old-school GUI techniques isn't a proper fit. Traditional Qt Widgets, yes, but QML is indeed not far from the React-style of GUI programming.
  - rumanator 7y ago
    > Traditional Qt Widgets, yes No you're still quite wrong. QWidgets-based UIs still consist of a DOM driven by a state machine that handles events. UI files have a 1:1 correspondence with components and state machines still control changes to the widget/DOM tree.
    - hellofunk 7y ago
      But are widgets reactive in the way QML is? That’s the issue.
delfinom 7y ago
>It's nice to see that the traditional desktop GUI programmers finally realize that the way the Web people do GUIs is right (React/Vue/...) and the way they did it until now (QT/GTK/WPF/...) is wrong. What? How is WPF any different than a web based ui framework. It does differential rendering, it uses hierarchical components in XML. WPF can update the UI with state changes on the backing C# without update commands, etc.
- for_the_many 7y ago
  When I used it, WPF only had two way binding. The recommended way to use React/Vue is with one way unidirectional binding (Redux/Vuex). It's a huge difference, and simplifies things a lot. Maybe WPF can do this today, I don't know, haven't touched it in 10 years. Another aspect, while WPF might check the feature list of React/Vue, using it in practice is kind of clunky.
  - pjmlp 7y ago
    Long time ago, because .NET 4 already had multiple bindings.
  - nwallin 7y ago
    .NET Framework 3.0 was initially released November 21st, 2006. React.js was initially released May 29th, 2013. There were 2381 days between differentiating between various binding types in WPF (which include one way, both OneWay and OneWayToSource) and React's release. There were 2378 days between React's release and today. So it took React longer to copy one way bindings from WPF than it took this project to "copy" React. Too bad you didn't make this comment on Thursday.
    - anp 7y ago
      If moxie brings anything new to the table, it’s only because I copied liberally and shamelessly from React and other successful and interesting projects, learning and improving on them in the process. If it doesn’t bring anything new, then it’s because I copied liberally and shamelessly from successful and interesting projects :P. I’m flattered to be compared to long standing paradigms I’ve had in mind (and others I am learning of now) while working on this.
raphlinus 7y ago
This is actually one of the reasons I'm so excited about the space. If it is possible to combine modern, Web-inspired ways of building UI with Rust's performance and other qualities, I think the result could be compelling. But we don't know yet, and I think what's needed now is an exploration of the various ways to adapt these reactive approaches into idiomatic Rust. I've been tracking Moxie and think it brings a lot to the conversation - I think Adam and I have been learning a lot from each other.
rumanator 7y ago
> It's nice to see that the traditional desktop GUI programmers finally realize that the way the Web people do GUIs is right and the way they did it until now (QT/GTK/WPF/...) is wrong. Can you provide any detail to corroborate your assertion? Because the Qt way of developing GUIs is based on a combination of a DOM, events and state machines to update the state of each subtree in the DOM.
WAHa_06x36 7y ago
Sure, if you don't care about transitions and animations at all. If you're wanting to do a really responsive and nice-feeling app, the react model hinders you far more than it helps.
jcelerier 7y ago
> It's nice to see that the traditional desktop GUI programmers finally realize that the way the Web people do GUIs is right (React/Vue/...) and the way they did it until now (QT/GTK/WPF/...) is wrong. c'mon, Qt has been doing declarative UI for the last ten years, before React and Vue even existed : https://patrickelectric.work/qmlonline/ https://patrickelectric.work/qmlonline/
- pier25 7y ago
  It may be declarative, but is it reactive? Edit: it may not sound that way but I swear I was honestly just asking a question. :)
  - jcelerier 7y ago
    yes ? in an even purer form than most JS frameworks : just using a variable creates a reactive binding. e.g. property int count: 0 Text { text: "counter " + count } Button { onClicked: count++ } will result in the text changing every time the button is clicked (for a complete code example you can paste in the previous link : import QtQuick 2.7 import QtQuick.Controls 2.3 Rectangle { id: root anchors.fill: parent property int count: 0 Column { Text { text: "counter " + count } Button { onClicked: count++ } } }
    - pier25 7y ago
      Thanks!
pier25 7y ago
As someone who started doing UI in the late 90s I totally agree. AFAIK Flutter and SwiftUI are bringing those web ideas into mobile/desktop dev. AFAIK there is still nothing similar in the C++ world.
- zelly 7y ago
  Flutter is available for C++ desktop programming. You just cannot do all the UI logic in C++; you have to use Dart.
  - pier25 7y ago
    > Flutter is available for C++ desktop programming I know Flutter for desktop is in process. Any link with more info?
tracker1 7y ago
What you're describing is pretty much how a LOT of game UIs have been developed for YEARS before React/Vue... in fact, I was doing similar with E4X in browser half a decade before React (though without chrome or ie support, it was kind of a dead end).
seanalltogether 7y ago
I completely disagree. I've been working react native and the whole thing feels like an inefficient abstraction designed to improve the lives of people who have to work in browsers every day. Web pages are stateless document trees, and libraries like react were designed to overcome those inherent problems when trying to build interactive features. Desktop/mobile applications frameworks are designed to be stateful component trees and have design patterns to help juggle interaction, data and views more effeciently.
adev_ 7y ago
> It's nice to see that the traditional desktop GUI programmers finally realize that the way the Web people do GUIs is right (React/Vue/...) and the way they did it until now (QT/GTK/WPF/...) is wrong. Ironically, it's quite the opposite. It's quite funny to see React people seeing their thing as a "GUI revolution" when React's approach have existed for 10/20 years in the traditional GUI world. - Component oriented approach: Done by Qt, GTK, WPF, OSX for more than 20 years: - Reactive design: Qt and other have done that for 15 years. - Stateless Immediate rendering: IMGUI and nuklear have done it for 10 years. - Pub/Sub event dispatch: Call it signal/slot and you had it in Qt/GTK for 15 years. - DOM specified GUI, call it XUL, XAML or Qt XML and you had it for 10 years. One more proof that the tech world is often a continuous reinvention with a lot of hype.

anp 7y ago

> traditional desktop GUI programmers finally realize FWIW, I'm not a desktop GUI programmer nor am I an...uh...professional GUI programmer of any kind. Not sure exactly who is doing the realizing here, but if they are, then great!? > the way the Web people do GUIs is right There are definitely some attractive things about web frameworks' approaches, but it's important to remember that the history of "declarative UI" traces a path back through C++ imgui devtools before React happened. I see the transition here differently -- the web is so opinionated about the DOM and its rendering engine, the only thing you can iterate on to make yourself more productive is the frontmost application semantics. Full-pipeline UI toolkits have to manage changes across all the various phases of their implementations. This (I think) creates an environment where the web is a great incubator for application model experimentation. However, many projects that start on the web have a difficult time faithfully mapping to the semantics of other GUI systems (one of the driving forces behind Electron adoption IMO). This gap is one that moxie hopes to bridge -- ideally we should be able to learn from the highly productive web ecosystem while transferring those learnings further into the UI stack without the overhead and performance cliffs of typical web tools.

layoutIfNeeded 7y ago

> The big one is just how much more better and efficient React/Vue/... are at creating GUIs Efficiency is not the first thing that pops to my mind when I look at the Electron-based apps in my task manager.

Tronno 7y ago
They were probably referring to speed/ease of development, not application performance.
- Gibbon1 7y ago
  > application performance I feel like this has suffered because the end users aren't the ones paying the bills in web space.

kibwen 7y ago

I'm no UI programmer, but this is such a strong claim that I would ask you to elaborate further.

eitland 7y ago

I tell you what was efficient for creating GUIs: The old Visual Basic (and I've also heard Delphi.) Doesn't mean I want them anywhere near my projects. The web is somewhat better thanks to declarative UI (for those that use it) and separation of concerns (again for those who take advantage of it).

pjmlp 7y ago
You can do declarative UI with Forms as well, it just takes a bit more of code than WPF to set up the data binding contexts and layouts.

fla 7y ago

I don’t think this statement is correct.For example Qt has been doing declarative with QML for years.

hellofunk 7y ago
I generally agree with the OP except that lumping QML into the old-school GUI techniques isn't a proper fit. Traditional Qt Widgets, yes, but QML is indeed not far from the React-style of GUI programming.
- rumanator 7y ago
  > Traditional Qt Widgets, yes No you're still quite wrong. QWidgets-based UIs still consist of a DOM driven by a state machine that handles events. UI files have a 1:1 correspondence with components and state machines still control changes to the widget/DOM tree.
  - hellofunk 7y ago
    But are widgets reactive in the way QML is? That’s the issue.

delfinom 7y ago

>It's nice to see that the traditional desktop GUI programmers finally realize that the way the Web people do GUIs is right (React/Vue/...) and the way they did it until now (QT/GTK/WPF/...) is wrong. What? How is WPF any different than a web based ui framework. It does differential rendering, it uses hierarchical components in XML. WPF can update the UI with state changes on the backing C# without update commands, etc.

for_the_many 7y ago
When I used it, WPF only had two way binding. The recommended way to use React/Vue is with one way unidirectional binding (Redux/Vuex). It's a huge difference, and simplifies things a lot. Maybe WPF can do this today, I don't know, haven't touched it in 10 years. Another aspect, while WPF might check the feature list of React/Vue, using it in practice is kind of clunky.
- pjmlp 7y ago
  Long time ago, because .NET 4 already had multiple bindings.
- nwallin 7y ago
  .NET Framework 3.0 was initially released November 21st, 2006. React.js was initially released May 29th, 2013. There were 2381 days between differentiating between various binding types in WPF (which include one way, both OneWay and OneWayToSource) and React's release. There were 2378 days between React's release and today. So it took React longer to copy one way bindings from WPF than it took this project to "copy" React. Too bad you didn't make this comment on Thursday.
  - anp 7y ago
    If moxie brings anything new to the table, it’s only because I copied liberally and shamelessly from React and other successful and interesting projects, learning and improving on them in the process. If it doesn’t bring anything new, then it’s because I copied liberally and shamelessly from successful and interesting projects :P. I’m flattered to be compared to long standing paradigms I’ve had in mind (and others I am learning of now) while working on this.

raphlinus 7y ago

This is actually one of the reasons I'm so excited about the space. If it is possible to combine modern, Web-inspired ways of building UI with Rust's performance and other qualities, I think the result could be compelling. But we don't know yet, and I think what's needed now is an exploration of the various ways to adapt these reactive approaches into idiomatic Rust. I've been tracking Moxie and think it brings a lot to the conversation - I think Adam and I have been learning a lot from each other.

rumanator 7y ago

> It's nice to see that the traditional desktop GUI programmers finally realize that the way the Web people do GUIs is right and the way they did it until now (QT/GTK/WPF/...) is wrong. Can you provide any detail to corroborate your assertion? Because the Qt way of developing GUIs is based on a combination of a DOM, events and state machines to update the state of each subtree in the DOM.

WAHa_06x36 7y ago

Sure, if you don't care about transitions and animations at all. If you're wanting to do a really responsive and nice-feeling app, the react model hinders you far more than it helps.

jcelerier 7y ago

> It's nice to see that the traditional desktop GUI programmers finally realize that the way the Web people do GUIs is right (React/Vue/...) and the way they did it until now (QT/GTK/WPF/...) is wrong. c'mon, Qt has been doing declarative UI for the last ten years, before React and Vue even existed : https://patrickelectric.work/qmlonline/ https://patrickelectric.work/qmlonline/

pier25 7y ago
It may be declarative, but is it reactive? Edit: it may not sound that way but I swear I was honestly just asking a question. :)
- jcelerier 7y ago
  yes ? in an even purer form than most JS frameworks : just using a variable creates a reactive binding. e.g. property int count: 0 Text { text: "counter " + count } Button { onClicked: count++ } will result in the text changing every time the button is clicked (for a complete code example you can paste in the previous link : import QtQuick 2.7 import QtQuick.Controls 2.3 Rectangle { id: root anchors.fill: parent property int count: 0 Column { Text { text: "counter " + count } Button { onClicked: count++ } } }
  - pier25 7y ago
    Thanks!

pier25 7y ago

As someone who started doing UI in the late 90s I totally agree. AFAIK Flutter and SwiftUI are bringing those web ideas into mobile/desktop dev. AFAIK there is still nothing similar in the C++ world.

zelly 7y ago
Flutter is available for C++ desktop programming. You just cannot do all the UI logic in C++; you have to use Dart.
- pier25 7y ago
  > Flutter is available for C++ desktop programming I know Flutter for desktop is in process. Any link with more info?

tracker1 7y ago

What you're describing is pretty much how a LOT of game UIs have been developed for YEARS before React/Vue... in fact, I was doing similar with E4X in browser half a decade before React (though without chrome or ie support, it was kind of a dead end).

seanalltogether 7y ago

I completely disagree. I've been working react native and the whole thing feels like an inefficient abstraction designed to improve the lives of people who have to work in browsers every day. Web pages are stateless document trees, and libraries like react were designed to overcome those inherent problems when trying to build interactive features. Desktop/mobile applications frameworks are designed to be stateful component trees and have design patterns to help juggle interaction, data and views more effeciently.

adev_ 7y ago

> It's nice to see that the traditional desktop GUI programmers finally realize that the way the Web people do GUIs is right (React/Vue/...) and the way they did it until now (QT/GTK/WPF/...) is wrong. Ironically, it's quite the opposite. It's quite funny to see React people seeing their thing as a "GUI revolution" when React's approach have existed for 10/20 years in the traditional GUI world. - Component oriented approach: Done by Qt, GTK, WPF, OSX for more than 20 years: - Reactive design: Qt and other have done that for 15 years. - Stateless Immediate rendering: IMGUI and nuklear have done it for 10 years. - Pub/Sub event dispatch: Call it signal/slot and you had it in Qt/GTK for 15 years. - DOM specified GUI, call it XUL, XAML or Qt XML and you had it for 10 years. One more proof that the tech world is often a continuous reinvention with a lot of hype.