Some of the criteria are insanely subjective.
For example: look. First off, as far as I remember, Qt and Gtk can be configured to use the OS theme, which mean that your GUI will respect the overall desktop theme. Electron does nothing of the sort and rely entirely on you to provide a good looking design.
Responsive UI: Depending on how you use Qt or Gtk, you can easily be responsive using the various layout provided, at no extra cost.
Finally, one big point that is not mentioned is accessibility. If most browser handle accessibility very nicely with the basic HTML components, if you start to do anything remotely advanced you gonna have to be careful and correctly implement ARIA norm, which most don't. Native UI framework are not perfect either, but can behave better in a lot of cases (it's not a clear cut though).
Electron or local-server + webapp is really nice. Having done front end development as well has "native" application (with Qt), I can really appreciate how easier it is do to custom components using web technology, but I think we tend to dismiss their disadvantages too quickly.
By Look I mean The ability to create advanced UI which are not influenced by the Desktop native theme (as are all successful end user oriented applications). The ability to create a native app which is at least beautiful as modern WebApps.
e.g. Slack or VS Code (Electron) are beautiful, while fractal or notecase (gtk) are not.
I also contend the supposed "ugliness" of gtk. This is at most a personal issue; in my view gtk programs are typically beautiful and Qt and Electron are unbearably ugly.
Definitely depends on the platform. On Linux it's probably great, but on macOS at least, I've yet to see a GTK app that doesn't feel super clunky. GTK breaks lots of expectations about how things should behave on macOS (shortcuts, standard menus, buttons, etc). Gimp or Inkscape are good examples. On the other hand those are examples of what a "native" app is expected to look like:
I recently started to use a gtk audiobook player (https://github.com/geigi/cozy, small plug as i've been very happy with it), and it looks absolutely fine to me. Of the three frameworks in the title traditional Qt Widgets apps to me look the worst.
It definitely depends on the platform and how much effort has been put in by the author. It is definitely ugly-by-default. Try Inkscape on Mac for example... that still uses XQuartz, maybe they're still on GTK2? Or try GIMP on Windows.
But there are more attractive apps that use GTK. They just have spent time doing custom themes.
Entirely depends on your system. On Linux/BSD with the right theme it can indeed look beautiful. I also quite enjoy the "plastic-y" feel it provides with some themes (like Clearlooks).
Hi, while I agree this criterion is highly subjective, I've based my analysis on the successful Desktop applications, and how it's easy/difficult to customize components.
I've not learned Rust yet, but unless it does behave really weird, I can't believe that Electron and Qt have roughly same RAM usage. In my experience Electron has usually 2 to 3 times higher RAM requirements than Qt application of similar scope.
I gave up trying to use native libraries for UI on cross-platform desktop programs.
I'm playing with the idea to create a Web UI and launch it automatically from the Rust server by opening a browser and pointing it at localhost. No electron bloat.
When it says gtk is "really really ugly", is it referring to API or UI? I wrote a small app with it and I am happy with the result. https://github.com/cosarara/fucking-weeb
>I then also have to remember what's the last episode I watched
I find it quite funny how many complicated solutions to this problem there are.
I simply stick a bunch of symlinks to whatever shows I am currently watching and remove them one by one. 20 line bash script + 1 minute configuring the file manager integration.
Gtk+ also has a lot of thrid party components. They may not be that discoverable, though. But you can look through a typical deps of a GNOME distribution to find some.
This is a pretty terrible write up; and I honestly don't know how the author subjectively arrived at the conclusion that only QT, GTK, and Electron are worth testing. I sort of wish context was given for this as the summary, as "get shit done" could hardly be implied from this list.
I don't understand the critic about subjective criteria, people commenting here seem to assume that the list is supposed to be an objective and complete comparison of GUIs. The author evaluated the solutions for their own needs, of course it will be subjective. If they find something too ugly for the UX they want to have, that's a perfectly valid reason to filter something out.
But that is still entirely subjective, i pretty much prefer Notecase/Fractal to Slack/VSCode.
As i wrote in another reply you probably want to rename this to themability (or customizability, but that can be a bit vague whereas themability is a common feature that one may want from a GUI toolkit) instead of look.
It's really sad to see that all the native options like druid got dismissed for being "not mature enough".
Guess I'll stick to WebAssembly and CLI Apps.
It's completely fair though, and I wouldn't want people trying to use druid while really basic functionality like menus is still being worked on. The only way I would recommend druid is if people want to roll up their sleeves and help build the toolkit.
If it's still dismissed in six months to a year, that would be sad.
> The following options exists but were not included because they are not mature enough.
> Web broswer communicating with a Rust local server: too much hacky, insecure? (DNS rebinding attacks) and does not support native features like tray icons.
You should not discount this, Golang solutions like lorca [0] do just fine with this using devtools proto for comm (systray can be a separate lib). DNS rebinding attacks are just a host header check away from mitigated. At the least, check out webview [1] (and its in-dev successor impl [2]) for not requiring Chrome and having more direct control.
Also, you should look at CEF which ships with Chromium bundled (it's not too huge) and has a C-FFI easily consumable from Rust. I have used this approach with success.
An important aspect to compare is docking. Any application that can span on multiple monitors, soon or later requires proper docking (window in window, etc.). Even if it's a single window, it's still a challenge.
Qt is almost there, but not as good as say Visual Studio (whatever docking framework they are using).
To be more blunt, any content creation tool (3D model/animation/etc editor) needs to support it. Take any Autodesk product for example (most of them use Qt).
Lately I’ve been experimenting with the idea of fully native cross platform desktop apps. Latest iteration is to write the majority of the app in Go and communicate with a native frontend over TCP. So far I’m finding that building a really simple UI and communicating over TCP to be pretty simple. At the same time I keep the majority of the business logic in the go server. It probably doesn’t work for all app types but it is fun to play with.
With Rust I imagine taking advantage of LLVM you could just import the business logic into whatever app environment you need to and work it that way. Has anyone here tried that? I would love to hear how it went.
> Latest iteration is to write the majority of the app in Go and communicate with a native frontend over TCP
You need a protocol over TCP. Something standard and easy to use, hopefully one that people already know and has wide support from libraries. HTTP?
Native UIs are nice, but the cool kids like to stylize their UIs. Things like gradients, shadows, highlights, animations, etc. And wouldn't it be cooler if you go to all that trouble to stylize your UI to have it look the same on all platforms? What if you add another layer on top of the underlying UI framework? Something that lets you compose UI elements from basic shapes, maybe a way to separate the layout from the style? HTML + CSS.
I've mentioned imgui too, and posted link to your comment. It needs to be evaluated here too. Coming from the game development world, there is a big appeal to the framework. It's author is responsive, the size is small, and the features are really what a game tool, or in-game debug screen may want. Easy to integrate, with various gfx backends (opengl, direct3d, etc.), and supports things that are not even done well by some of the other frameworks - like docking (which I've mentioned in my post).
It has quirks, biggest one (to me), being how to deal when you have lots of widgets and their state (e.g. the hidden state labeling), then with my personal experiments I've found cases where the UI would lock, when flowing text, but overall seems to work well.
On the other end, I'm really happy (myself) with Flutter, but then it misses the stuff that I just mentioned, though for a mobile app - you may (and most likely not) need these requirements.
So two important, and recently new frameworks not included, I think they should... Flutter is direct competitor to Electron (now available on the desktop), and IMGUI to Qt/GTK.
[+] [-] maeln|6 years ago|reply
Finally, one big point that is not mentioned is accessibility. If most browser handle accessibility very nicely with the basic HTML components, if you start to do anything remotely advanced you gonna have to be careful and correctly implement ARIA norm, which most don't. Native UI framework are not perfect either, but can behave better in a lot of cases (it's not a clear cut though).
Electron or local-server + webapp is really nice. Having done front end development as well has "native" application (with Qt), I can really appreciate how easier it is do to custom components using web technology, but I think we tend to dismiss their disadvantages too quickly.
[+] [-] Liquid_Fire|6 years ago|reply
[+] [-] z0mbie42|6 years ago|reply
By Look I mean The ability to create advanced UI which are not influenced by the Desktop native theme (as are all successful end user oriented applications). The ability to create a native app which is at least beautiful as modern WebApps.
e.g. Slack or VS Code (Electron) are beautiful, while fractal or notecase (gtk) are not.
[+] [-] enriquto|6 years ago|reply
[+] [-] mraison|6 years ago|reply
https://www.sketch.com
https://paw.cloud
https://www.pixelmator.com
Note that the apps above are not implemented with Qt or Electron either, they use the official Apple frameworks.
[+] [-] Barrin92|6 years ago|reply
[+] [-] IshKebab|6 years ago|reply
But there are more attractive apps that use GTK. They just have spent time doing custom themes.
[+] [-] throwaway8941|6 years ago|reply
[+] [-] z0mbie42|6 years ago|reply
[+] [-] langitbiru|6 years ago|reply
[+] [-] z0mbie42|6 years ago|reply
[+] [-] Hitton|6 years ago|reply
[+] [-] z0mbie42|6 years ago|reply
In the context of the article, the UI is in HTML/JS and the business logic in Rust, thus the RAM is not so high.
On the other hand, Qt QML embed it's own JS engine which is not resources light.
[+] [-] hacker_9|6 years ago|reply
[+] [-] generichuman|6 years ago|reply
I'm playing with the idea to create a Web UI and launch it automatically from the Rust server by opening a browser and pointing it at localhost. No electron bloat.
Has anyone tried this, any thoughts?
[+] [-] cosarara|6 years ago|reply
[+] [-] throwaway8941|6 years ago|reply
I find it quite funny how many complicated solutions to this problem there are.
I simply stick a bunch of symlinks to whatever shows I am currently watching and remove them one by one. 20 line bash script + 1 minute configuring the file manager integration.
[+] [-] blattimwind|6 years ago|reply
Both? Mostly the former? Largely the latter (depending on plattform)?
[+] [-] megous|6 years ago|reply
[+] [-] heavenlyblue|6 years ago|reply
[+] [-] z0mbie42|6 years ago|reply
I also heard that the API have some misfit with Rust ownership model: https://news.ycombinator.com/item?id=20368618
[+] [-] rubyn00bie|6 years ago|reply
Just my two cents.
[+] [-] z0mbie42|6 years ago|reply
Maybe you can do your own so you can tell us the GiGa TrUtH about modern GUI frameworks.
[+] [-] amelius|6 years ago|reply
[+] [-] dgellow|6 years ago|reply
[+] [-] leshow|6 years ago|reply
Unless you mean 'responsive' like 'works on mobile'. Which seems kind of a moot point considering we're talking about desktop applications.
[+] [-] anchpop|6 years ago|reply
[+] [-] z0mbie42|6 years ago|reply
It's useful because we see more and more 'convergent devices' like the librem 5, pr a raspberry pi with a 10' screen
[+] [-] z0mbie42|6 years ago|reply
I understand the critics against the subjective criteria like "Look".
Look means: the ability to create a native app which is at least beautiful as modern WebApps.
e.g. Slack or VSCode (Electron) are beautiful, while fractal or NoteCase (Gtk) are not.
[+] [-] Crinus|6 years ago|reply
As i wrote in another reply you probably want to rename this to themability (or customizability, but that can be a bit vague whereas themability is a common feature that one may want from a GUI toolkit) instead of look.
[+] [-] techntoke|6 years ago|reply
[+] [-] kuriho|6 years ago|reply
[+] [-] raphlinus|6 years ago|reply
If it's still dismissed in six months to a year, that would be sad.
[+] [-] littlestymaar|6 years ago|reply
And unfortunately, Azul was abandoned by its maintainer a few month ago for family reasons, so it's unlikely to be polished anytime soon.
At this point there is no viable full-Rust GUI toolkit, but druid may be one at some point.
[+] [-] c-smile|6 years ago|reply
but conclusion "The most promising seems to be Flutter" was made already :)
[+] [-] kodablah|6 years ago|reply
> Web broswer communicating with a Rust local server: too much hacky, insecure? (DNS rebinding attacks) and does not support native features like tray icons.
You should not discount this, Golang solutions like lorca [0] do just fine with this using devtools proto for comm (systray can be a separate lib). DNS rebinding attacks are just a host header check away from mitigated. At the least, check out webview [1] (and its in-dev successor impl [2]) for not requiring Chrome and having more direct control.
Also, you should look at CEF which ships with Chromium bundled (it's not too huge) and has a C-FFI easily consumable from Rust. I have used this approach with success.
0 - https://github.com/zserge/lorca 1 - https://github.com/zserge/webview 2 - https://github.com/zserge/webview/tree/webview-x
[+] [-] baby|6 years ago|reply
[+] [-] malkia|6 years ago|reply
Qt is almost there, but not as good as say Visual Studio (whatever docking framework they are using).
To be more blunt, any content creation tool (3D model/animation/etc editor) needs to support it. Take any Autodesk product for example (most of them use Qt).
Dear IMGUI in this respect added recently pretty good docking system, and it's not in this list - someone else also mentioned that https://news.ycombinator.com/item?id=20776848
Thanks!
[+] [-] jcelerier|6 years ago|reply
It closes the gap a fair bit with the VS docking system
[+] [-] todd3834|6 years ago|reply
With Rust I imagine taking advantage of LLVM you could just import the business logic into whatever app environment you need to and work it that way. Has anyone here tried that? I would love to hear how it went.
[+] [-] c-smile|6 years ago|reply
Check Sciter/Go : https://github.com/sciter-sdk/go-sciter
It is used precisely that way: backend - Go, UI - Sciter.
[+] [-] rootlocus|6 years ago|reply
You need a protocol over TCP. Something standard and easy to use, hopefully one that people already know and has wide support from libraries. HTTP?
Native UIs are nice, but the cool kids like to stylize their UIs. Things like gradients, shadows, highlights, animations, etc. And wouldn't it be cooler if you go to all that trouble to stylize your UI to have it look the same on all platforms? What if you add another layer on top of the underlying UI framework? Something that lets you compose UI elements from basic shapes, maybe a way to separate the layout from the style? HTML + CSS.
Oh wait, we reinvented electron again.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] billfruit|6 years ago|reply
[+] [-] ScottFree|6 years ago|reply
[+] [-] malkia|6 years ago|reply
It has quirks, biggest one (to me), being how to deal when you have lots of widgets and their state (e.g. the hidden state labeling), then with my personal experiments I've found cases where the UI would lock, when flowing text, but overall seems to work well.
On the other end, I'm really happy (myself) with Flutter, but then it misses the stuff that I just mentioned, though for a mobile app - you may (and most likely not) need these requirements.
So two important, and recently new frameworks not included, I think they should... Flutter is direct competitor to Electron (now available on the desktop), and IMGUI to Qt/GTK.
[+] [-] dgellow|6 years ago|reply
https://github.com/ocornut/imgui
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] bvda|6 years ago|reply
[+] [-] Narishma|6 years ago|reply