7 ms·

I've done professional GUI programming and there are really only three options that make sense: 1. Write the GUI natively per platform. This is best from a UX

• forrestthewoods 5y ago
  Good post. However I think you need to differentiate between GUI for internal tools and customer facing products. Dear ImGui is pretty damn stellar for internal tools. Nigh unbeatable along certain axes. Rust has a couple of Dear ImGui inspired libraries. I think for tools and editors Rust is getting close to being perfectly viable. For customer facing GUI I largely agree with your assessment.
• k__ 5y ago
  Tauri seems like the only viable Electron alternative right now, and it's written in Rust.
  • adrusi 5y ago
    It's not very clear from their docs, but it looks like tauri is mostly a way to launch a system WebView from rust and communicate with it via message passing. Doesn't really seem like a GUI toolkit for rust, since all the GUI stuff is going to be done in JS.
    • xtagon 5y ago
      The same can be said of Electron.
      • YorickPeterse 5y ago
        The difference is that Electron guarantees you're always using a known version/engine. With Tauri, you'd be using whatever is installed, and that engine may behave different from what you are used to. So basically you get all the drawbacks of developing for different web browsers, without really any of the benefits a cross-platform GUI gives you.
        • wila 5y ago
          Just like building for the web then? In that scenario you also do not know what version the browser is (or even what kind of browser). An advantage would be that the browser gets security patches by the OS.
        • imbnwa 5y ago
          Is this really a problem now that IE11 is finally being deprecated? You basically have Blink/Gecko/Webkit which is no different from regular web dev
        • jokethrowaway 5y ago
          Does it use less RAM because it's shared with the system browser? I sure as hell avoid all the Electron based apps because of their memory consumption. Cross-browser compatibility is not too bad these days.
• bradrn 5y ago
  Wrt option (2), what do you think of other libraries like wxWidgets or GTK+? At least on Windows, the latter certainly doesn’t feel at all ‘nice to use’ (admittedly a subjective criterion), but I find I quite like programs made with wxWidgets.
  • jeffreyrogers 5y ago
    I've never used them, but they seem similar to Qt. For whatever reason Qt seems to be the most popular in commercial products.
    • asddubs 5y ago
      wxwidgets is unique in that it translates to native gui widgets (when available)
  • xiaomai 5y ago
    GTK+ on Rust is a thing that is seeing a lot of active work (see https://gtk-rs.org/ https://gtk-rs.org/). I think some of the core gnome stuff has even moved over to rust at this point (like libsrvg).
  • nonbirithm 5y ago
    I have used wxlua in the past and it's a seriously underrated feat of engineering in my opinion. It would be great if there were somehow a wrapper for wxwidgets that plays well with Rust, fingers crossed.
• kodablah 5y ago
  > Electron is popular because there are tons of web developers and they can be productive quickly. It's also popular because a browser engine as a lot features that are otherwise difficult to get (e.g. bandwidth-estimated multiplexed video streaming).
  • throwaway894345 5y ago
    Also accessibility and bulletproof text rendering and input handling and layout and a million other things that are a lot more involved than people think. I say this with great sadness as someone who wishes Electron wasn't the most practical solution at the moment.
• throwaway894345 5y ago
  > Use a custom GUI framework.[0] Probably the most expensive option and hard to hire developers for, but can be warranted for complex applications like CAD tools, games, etc This will also suck for users because things like focus, keyboard shortcuts, accessibility, non-English text rendering, etc will probably not work as expected if at all. It turns out there's a lot that goes into GUI that most of us take for granted.
• michaellee8 5y ago
  The third option is basically Flutter. Maybe Rust guys would like to do some Flutter bridge?
  • lenkite 5y ago
    A pretty amazing interop library at https://thlorenz.com/rid-site/ https://thlorenz.com/rid-site/
• jcelerier 5y ago
  > 1. Write the GUI natively per platform. This is best from a UX perspective but is expensive and you probably need different developers working on different platforms. Other downside is that really advanced functionality is harder to implement and sometimes the performance of native APIs is poor and hard to improve (Apple has this problem frequently). That really depends on the software though. I develop a media software and my users are adamant that they want the exact same look&feel across the three main desktop platforms (to the point that I had to use freetype everywhere for font rendering - thankfully easy with Qt). Also had the same case for a customer at a previous job - I remember comparing screenshots across macOS and Windows until they matched in a pixel-perfect way. On the other hand, if you're writing, say, a productivity app, calendar, notes manager, most likely it is better for it to fit to each platform. Although I personally also prefer to use the same apps across platforms, e.g. my main combo no matter whether I'm on Linux / macOS / Win32 is Zim for note-taking, Strawberry for music, Qt Creator for IDE, Seafile for data exchange, Telegram and ripcord for chat, Krita for image manipulation, Darktable for raw photo processing, Digikam for photo collection management ; DaVinci Resolve for video editing. With the exception of Zim and Darktable which are GTK, all the others are Qt-based.
  • Wowfunhappy 5y ago
    > I develop a media software and my users are adamant that they want the exact same look&feel across the three main desktop platforms Are these end-users, or just the person in charge? I find it hard to believe that the actual users of the software would care about this.
    • freedomben 5y ago
      > media software If this is editing audio or video, I can 100% believe that. Anything with complex controls that a user has to learn, or keyboard shortcuts, it really matters to end users. I worked on a Qt app quite a few years ago and that wasn't a media app but it was a complex GUI. Our end users also wanted the exact experience regardless of platform. On a related note, if you need a rich UI I totally recommend using Qt on the frontend and the backend. Qt isn't just UI libs. There are a bunch of super useful server-side libraries as well that you can use. We used protobufs and had unbelievable performance on the front end and backend. It was a beauty to behold.
• gfxgirl 5y ago
  Electron is popular because it gets the job done quickly. I can start a new Electron app in 10-20 minutes and build it across Linux/Mac/Windows in moments. There's almost no setup needed except node which is easy to install locally (nvm, nvm-windows). Most other solutions require installing large tool chains manually first and lots of pre-reqs and being familiar with those tool chains. On Electron I just "git clone proj && cd prog && npm i && npm run build && num run dist" and an installer/msi/dmg/AppImage pops out. I'm fully capable of writing a native app or using Qt but for a large number of apps my clients won't notice a difference and I can be finished faster with Electron so I use Electron. I even use to just provide a GUI shell over running command line tools. Sure it's "bloated" by some definition of bloated but I get the job done so much quicker and 99% of the cross platform issues disappear.
• Razengan 5y ago
  > sometimes the performance of native APIs is poor and hard to improve (Apple has this problem frequently). Compared to the alternatives (especially Electron, where you oddly forgot to mention this), the performance from native Apple APIs is often the best you can get. Have you looked at stuff like TextKit 2 etc.?
  • jeffreyrogers 5y ago
    I like Apple a lot, it is the most pleasant platform to develop for IMO, but performance depends a lot on what you're doing and how much they've optimized it.
• jokethrowaway 5y ago
  Conrod is targeting 3 and it does a decent job at that https://www.youtube.com/watch?v=_ZXLCVibI8c https://www.youtube.com/watch?v=_ZXLCVibI8c Themes are something they would like to implement and once they have themes they could do native looking themes like Qt (which are perfectly reasonable, I'm generally very happy as a user with Qt applications across all platforms) I agree with you there is not yet an audience big enough to justify a Qt written for Rust, but who knows, maybe something will change in the next years. That said, when I had to do something like this, I used Qt with Rust, just because I couldn't justify the time investment of reimplementing a native looking theme on top of Conrod.
• gregwebs 5y ago
  Why does Rust need to compete with QT? Most programming languages have QT bindings. Similarly, different languages could work with Electron through compile to JS/WASM.
• j1elo 5y ago
  I've worked as a GUI developer with Qt for years in the past, and I think that library/framework is an awesome technical feat. It would be a pity if Rust (or any other language, for that matter) had to start over from scratch and reinvent their own toolkit, instead of taking advantage of the years and heaps of applied knowledge (and optimizations) that some older toolkits already have. If all the man-hours required to design, write, and coordinate the creation of a GUI toolkit that's the same level of advanced and mature, are instead employed in overcoming any difficulty in creating the best possible bindings, we would end up with a heck of a good quality bindings for Qt and still probably for 1/10th of the human effort. All IMHO, of course.
  • nybble41 5y ago
    It's not just a matter of putting in enough man-hours to create decent bindings. Native-C++ libraries are hard to write good bindings for in the best of times, typically requiring C wrappers with limited functionality and/or significant runtime overhead. Creating workable and safe (but still non-idiomatic) bindings for a C++ library from a language like Rust with a very different object model (can't use C++ templates or define new C++ subclasses; functions called from Rust must not throw C++ exceptions) and a far stricter type system than either C or C++ (borrow checking, lifetimes, thread-safety enforced at the type level) can be next to impossible. Even if you succeed, the result will be restricted to the least common denominator supported by both C++ and Rust and will never feel like a native Rust library. This is not to say that Rust could not benefit from the significant effort which has gone into developing Qt, but a Rust port of Qt might be more workable than bindings to the C++ toolkit.
    • j1elo 5y ago
      > a Rust port of Qt might be more workable than bindings to the C++ toolkit. That's an interesting idea! it might be worth considering it, at least. I wasn't thinking of a full-blown bindings that cover 100% of the API which is an immense task and, as your sibling comments thinks, was a mistake. A more opinionated stance of what parts of the Qt features are deemed necessary seems more feasible in the short to medium term. I wasn't advocating for one specific way of doing it, but for the more general sentiment that reinventing the wheel and creating a new toolkit from scratch is definitely the most expensive of all the options, in terms of human effort, time dedicated, and progress achieved. We'd basically be decades later than other OSS options, why not build upon their shoulders instead?