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.
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.
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.
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.
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.
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.
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.
I'm not really qualified to compare wpf to react or moxie.
Second, liberally copying the best parts of other things and leaving the crappy parts behind is bringing something new to the table. Don't sell yourself short.
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.
c'mon, Qt has been doing declarative UI for the last ten years, before React and Vue even existed : https://patrickelectric.work/qmlonline/
Edit: it may not sound that way but I swear I was honestly just asking a question. :)
e.g.
property int count: 0
Text {
text: "counter " + count
}
Button {
onClicked: count++
}
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++
}
}
}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.
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.
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).
If you're wanting to do a really responsive and nice-feeling app, the react model hinders you far more than it helps.
Efficiency is not the first thing that pops to my mind when I look at the Electron-based apps in my task manager.
I feel like this has suffered because the end users aren't the ones paying the bills in web space.
AFAIK Flutter and SwiftUI are bringing those web ideas into mobile/desktop dev.
AFAIK there is still nothing similar in the C++ world.
I know Flutter for desktop is in process. Any link with more info?