1. 8

    Why do we need new GUI implementations? From an end user’s standpoint, they result in app UX that’s incompatible with other apps and often missing features like accessibility or platform integration. (Viz: everyone’s complaints about the UX of Electron apps like Slack.) From a developer’s standpoint, a new framework is yet another complex new API to learn, and likely means adding hacks to support platform-specific features.

    (Obviously if you’re building your own OS you’ll need a new GUI framework. But otherwise, just let me use UIKit or AppKit, kthxbye.)

    1. 9

      My understanding is that “cross platform desktop apps” are an unsolved problem. It’s not like we have N equally good alternatives. If you want to deliver a high quality UI-intensive cross platform desktop app which is a core to your business, your choices are:

      • use QT with either unsafe C++ or dynamically typed Python
      • build your own UI framework on top of Skia
      • compromise on high quality and pick electron/Swing/JavaFX/sciter
      • compromise on cross-platform and use mac stuff on mac, win stuff on win, and ¯\_(ツ)_/¯ on Linux
      1. 2

        Flutter basically chose your 2nd option, but then built a generic widget framework on top of it. It has its shortcomings, but it’s certainly an interesting project in this space.

        1. 1

          Flutter is another Swing/JavaFX/Electron/Sciter, but with a less popular programming language.

        2. 1

          As a developer it’s pretty obvious I should choose #3. As a user, anything other than #4 makes it pretty obvious the developers value my experience significantly less than their time.

        3. 6

          It would be nice to have a production-quality choice for a cross-platform GUI besides Electron or maybe Qt.

          1. 5

            Both serve to demonstrate that there is no such thing as cross-platform GUI.

          2. 2

            I suspect the major reason is a unified cross-platform development experience. I think the mobile space has shown that it’s too costly to maintain separate code based for iOS and Android. React Native has proven that many (most?) apps can be written once and deployed on both.

            1. 1

              I don’t agree with that.

              Providing separate native mobile applications is not a big problem, if done right. It means isolating core business logic to a layer that can be treated almost like a line-by-line translation (we use Kotlin and Swift), and keep UI layer similar where it can be, but embrace platform native solutions where appropriate.

              I think the allure of react-native is more than just the cross platform part. It’s about NodeJS - it attracts developers from a web/Node background.

              1. 3

                When I worked at a major music streaming company, we wrote cross-platform libraries for the non-UI bits, and built native UIs on top of that.

                So most code was shared, but users didn’t have to suffer with non-native UI.

            2. 2

              My experience with cross-platform applications makes me think common backend differrent frontends (assuming you can glue them with a common interface; UIKit is radically different from Win32) is the better alternative; but is economically unviable (why spend money twice or thrice when Electron exists and lets you use cheap webdevs?) as well as being poison for devs (why do I need develop the same thing thrice? what about Linux? clearly i could reimplement all this myself) who don’t really “get” platforms or UX.

              1. 1

                Check out the retrospective on the xi-editor project, which tried to use native GUIs and found that they’re overrated for some kinds of applications. This is what led to the Druid project.

                1. 6

                  That’s a pretty… opinionated, I guess? retrospective. I mean:

                  When doing some performance work on xi, I found to my great disappointment that performance of these so-called “native” UI toolkits was often pretty poor, even for what you’d think of as the relatively simple task of displaying a screenful of text. A large part of the problem is that these toolkits were generally made at a time when software rendering was a reasonable approach to getting pixels on screen. These days, I consider GPU acceleration to be essentially required for good GUI performance.

                  On the one hand, that sounds plausible.

                  On the other hand, considering that, between macOS and Windows, we have text editors and IDEs that have hundreds of millions of happy users, which are very efficiently used to write software worth billions of dollars, every day, maybe these “so-called ‘native’ UI toolkits” aren’t that bad. Or, okay, maybe they’re not too good, but one developer’s failed attempt to use them to write an editor up to their standard is probably not enough of a sample to say it’s high time we replaced them with something better.

                  The author then goes on to discover that their own, high-performance implementation then doesn’t have any of the benefits of native toolkits. Well, yeah, like virtually all engineering problems, this one ends with a trade-off, too. Beating the performance of 30 year-old GUI toolkits with a small toolkit written today is probably not that complicated. But beating the reliability of a 30 year-old toolkit, even without feature parity, is a multi-year project. 30 years of bugfixes is no mean feat.

              1. 1

                Amazing. I haven’t heard about ESE in ages. I know it’s the original engine used by RavenDB.

                1. 2

                  One thing I’m curious about: how is it calling to/from Rust from Swift? I’d love to have app core logic in Rust if possible in some cases.

                  1. 3

                    The core is in Rust. The Mac frontend is in Rust. It’s using xml-rpc so front ends and other plug ins can be written in any language. I had/have high hopes this would replace Emacs for me (no reason to drop emacs really other than to have something more modern/fast.

                    While development does continue, sadly it seems to be mired in it’s design choices. But… Emacs is getting lots of attention on it’s internals, so it may be moot ;)

                    1. 1

                      Small correction. The Mac front end is Swift. The xi core is launched as a separate process by the front end and communication between the processes occurs via JSON over STDIN/STDOUT.


                      1. 2

                        Sorry, just a brain fart when typing that up, I knew that it was swift.

                    2. 2

                      Rust has the “extern c” directive to give you a c calling convention when building shared libraries. It’s a little unergonomic on the rust side as you have to convert between eg c and rust strings but jot too bad.

                      1. 1

                        Yup, and Swift can parse C headers and lets you call C functions in a similar way. Binding Rust to Swift in-process would just be a matter of declaring a suitable C interface between them.