1. 23
  1.  

  2. 8

    Whenever I read about yet another GUI toolkit that doesn’t use native widgets, I want to scream, “No! Don’t!” Here’s a comment that succinctly lists several problems with non-native widgets. Many of them are macOS-specific, but some are applicable to any platform.

    1. 8

      while this appeals to the purist, we are no longer just dealing with the QTs and wxWidgets of the world. The evil facing us is a multi-100mbs heavy electron app that eats similar amounts of RAM for showing a few widgets on screen (eg: privtunl’s toolbar).

      1. 3

        “Evil” is an awfully strong word in this context. For all of Electron’s problems, at least it inherits Chromium’s support for platform accessibility APIs (on Windows and Mac). This makes Electron infinitely better for, say, a blind user who relies on a screen reader, compared to a typical non-native GUI toolkit with no accessibility support. Of course, for many users, like the author of the comment I linked previously, a truly native GUI would be better still. But let’s not block some users from using our applications because Electron offends our aesthetic sense.

      2. 4

        I have not tried it, but for native widgets there is also https://github.com/briskml/brisk that seems promising

        1. 2

          What can someone even use to make cross platform native apps with native widgets? I’ve been looking for a desktop UI framework to use but it looks like the only “good” way is to rewrite the UI once with Cocoa, once with whatever Windows uses (is there even a standard?), and once with GTK+.

          1. 3

            Things like wxWidgets and Eto use native widgets. Of course the result is going to look a bit weird because macOS, Windows and GTK have very different UI idioms and showing the same UI everywhere would look out of place everywhere (except Windows, where inconsistency is kinda the norm, and MS has multiple independent UI toolkits as part of the system). But with great effort, you could put platform specific adaptations with these frameworks and make it look okay.

          2. 2

            I think this only applies to mac. And even then only minimally.

            Linux doesn’t even really have a native, there’s qt, gtk, and then <random other apps> that all make up the core parts of any given system and all style differently.

            Windows technically has a native, but not even microsoft seems to care about it anymore.

            The vast majority of time spent on most computers is probably in the web browser, which on all platforms does not look “native”.

            Arguably “native” these days should probably mean “imitate the web” not “use OS APIs” since that’s what most people are “native” to anyways.

            1. 1

              I think this only applies to mac.

              Almost certainly. There are many people who use a Mac because it’s Unix with a usable interface; many (although fewer these days) who use them because it’s what they had in school; but there are some, and this is a shrinking minority, I fear, who use Macs because they prefer the Macintosh, and they make an affirmative choice to dwell in the Mac, and select their tools based on how well they conform to platform convention. This is not a thing that people who prefer Windows or non-Mac Unixes has ever used as a decision procedure.

          3. 6

            So I just skimmed the docs for a quick second, and it states that react-native essentially “packs a browser” into an app, hence the high cpu/ram usage, but then the readme sort of just denies this is a problem for revery? Without really explaining why? Hate to be that ignorant fool in the thread, but could someone explain to me how exactly this works? I’m not a frontend/js guy, and I love ocaml, but I have no idea how any of this stuff is supposed to work. How is something “native” if its not actually locally compiled machine code? thanks in advance for any takers on this

            1. 4

              The same Reason/OCaml code will compile down to / bind to the low level graphics libraries (ie., GL) when targeting native platforms and the “OpenGL” parts of the browser when targeting Javascript.

              1. 2

                thanks for taking the time to explain.