Hacker News new | past | comments | ask | show | jobs | submit login

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.

> 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.

> 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.

>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.

I agree. Doing MVVM in WPF/XAML felt like an incredibly natural transition from web frameworks for me. In fact, from a high-level standpoint it feels uncannily similar to working in Angular and TypeScript.

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.

.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.

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.

I'm really only commenting on the idea that wpf doesn't have one way binding. People saying dumb stuff on the internet makes me mad. Personal failing. Like that was added in 2006. That feature was coreleased with Windows Vista and IE7. Google had just bought YouTube for $1.65bn and people were incredulous about such a stupid decision on Google's part. One way binding in wpf was released to the public three months after jQuery. It's a year older than silverlight, which is significant because silverlight just took everything that wpf was and said, "what if we could make web pages this way?" Arguably without silverlight the react folks never ask, "what if silverlight wasn't completely shitty?"

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.

Can you point me to a good introduction (document, blog post, video) to the way WPF does this? I'm actually quite interested in the older systems, especially because a lot of them come from a place where massive complexity is not seen as a good thing.

Long time ago, because .NET 4 already had multiple bindings.

In fact WPF original team was composed by ex-IE developers, if I am not mistaken.

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.

> 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/

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. :)

yes ? in an even purer form than most JS frameworks : just using a variable creates a reactive binding.


    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++


> 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.

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.

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

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.

> 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.

But are widgets reactive in the way QML is? That’s the issue.

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

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).

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.

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.

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).

> 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.

They were probably referring to speed/ease of development, not application performance.

> application performance

I feel like this has suffered because the end users aren't the ones paying the bills in web space.

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.

Flutter is available for C++ desktop programming. You just cannot do all the UI logic in C++; you have to use Dart.

> Flutter is available for C++ desktop programming

I know Flutter for desktop is in process. Any link with more info?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact