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.<p>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).<p>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.
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.
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.<p>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.<p>Has anyone tried this, any thoughts?
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. <a href="https://github.com/cosarara/fucking-weeb" rel="nofollow">https://github.com/cosarara/fucking-weeb</a>
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.<p>Just my two cents.
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.
How are you going to claim that Gtk doesn't have a 'responsive UI'? It's native, it's very responsive.<p>Unless you mean 'responsive' like 'works on mobile'. Which seems kind of a moot point considering we're talking about desktop applications.
Hi, author here,<p>I understand the critics against the subjective criteria like "Look".<p>Look means: the ability to create a native app which is at least beautiful as modern WebApps.<p>e.g. Slack or VSCode (Electron) are beautiful, while fractal or NoteCase (Gtk) are not.
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.
Sciter/Rust (<a href="https://github.com/sciter-sdk/rust-sciter" rel="nofollow">https://github.com/sciter-sdk/rust-sciter</a>) was not tested: <a href="https://gitlab.com/z0mbie42/rust_gui_ecosystem_overview#not-tested" rel="nofollow">https://gitlab.com/z0mbie42/rust_gui_ecosystem_overview#not-...</a><p>but conclusion "The most promising seems to be Flutter" was made already :)
> The following options exists but were not included because they are not mature enough.<p>> Web broswer communicating with a Rust local server: too much hacky, insecure? (DNS rebinding attacks) and does not support native features like tray icons.<p>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.<p>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.<p>0 - <a href="https://github.com/zserge/lorca" rel="nofollow">https://github.com/zserge/lorca</a>
1 - <a href="https://github.com/zserge/webview" rel="nofollow">https://github.com/zserge/webview</a>
2 - <a href="https://github.com/zserge/webview/tree/webview-x" rel="nofollow">https://github.com/zserge/webview/tree/webview-x</a>
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.<p>Qt is almost there, but not as good as say Visual Studio (whatever docking framework they are using).<p>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).<p>Dear IMGUI in this respect added recently pretty good docking system, and it's not in this list - someone else also mentioned that <a href="https://news.ycombinator.com/item?id=20776848" rel="nofollow">https://news.ycombinator.com/item?id=20776848</a><p>Thanks!
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.<p>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.
I feel that the brushed metal tone or shading that earlier gnome/2.x gtk+ had was very aesthetically pleasing, not seen it replicated anywhere else.
It's almost if the GUI ecosystem is mostly independent of the language used. That's because GUI frameworks are a lot of work, so it makes more sense to have bindings to existing ones.
An Electron flame war seems inevitable. It's fine for quick cross platform support but it absolutely screws over the user. QT is <i>far</i> from perfect but at least it's native.
I for long searched for a way to use GTK from nodejs. There are some proof of concept level bindings, but none exposing any much decent amount of the underlying functionality.<p>Same for Qt I think