
Rust GUI ecosystem overview - z0mbie42
https://gitlab.com/z0mbie42/rust_gui_ecosystem_overview
======
maeln
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.

~~~
z0mbie42
Hi, thank you for the feedback.

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
> (...) is at least beautiful as modern WebApps.

What? In my dictionary, screenshots of "modern webapps" appear when I search
the definition of the word "ugly".

~~~
anichale
Would you consider the Stripe[0] dashboard or Figma[1] ugly? I'm not agreeing
with the parent's statement, but whether or not a WebApp or Native App is ugly
is impacted more by designers, not implementation.

[0]: [https://stripe.com](https://stripe.com) [1]:
[https://www.figma.com](https://www.figma.com)

~~~
enriquto
Yes, they are the worst kind of site and they represent fairly everything that
I dislike about the "modern" web. Superfluous animations, not clear where to
click, and with an overall design that is so standard that is not evident
whether it is a parody or not [0]. I pretty much prefer clean designs with
clearly visible links, like wikipedia, or hackernews, or the recently
discussed today sourcehut [1]

[0] [http://tiffzhang.com/startup](http://tiffzhang.com/startup)

[1]
[https://git.sr.ht/~sircmpwn/git.sr.ht/tree](https://git.sr.ht/~sircmpwn/git.sr.ht/tree)

------
enriquto
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.

~~~
mraison
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:

[https://www.sketch.com](https://www.sketch.com)

[https://paw.cloud](https://paw.cloud)

[https://www.pixelmator.com](https://www.pixelmator.com)

Note that the apps above are not implemented with Qt or Electron either, they
use the official Apple frameworks.

~~~
ScottFree
This is something I've always wondered and still can't find a good answer to:
why are MacOS apps so damned beautiful and plentiful compared to linux and
windows apps? Are the official Apple frameworks just that easy and pleasant to
work with? I hear devs complain about ObjectiveC all the time, so it can't be
their language choice. Or is it another example of Steve Job's reality
distortion field, but applied to the entire MacOS application developer
community?

~~~
enriquto
> why are MacOS apps so damned beautiful and plentiful compared to linux and
> windows apps?

This is entirely subjective. Several of my colleagues use MacOS and I find
their interfaces overcrowded and clunky compared to my minimal linux setup.
What is "plenty" to some, is "clutter" to others.

~~~
ScottFree
While I respect your opinion and personal taste, it is not shared by the
majority of app users. If it was, linux apps would dominate and webapps
wouldn't.

~~~
enriquto
Sure, taste is not a democratic thing.

------
Hitton
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.

~~~
z0mbie42
It's because almost all electron apps are written fully in JS.

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.

~~~
kelnos
Did you come to this conclusion by taking measurements using real apps?
Because if this is just your gut feeling, that doesn't make sense. The base
memory footprint of something like Electron (just a simple Hello World app) is
likely already heavier than a complete Rust-only GUI app.

For a GUI app, business logic is usually not where your RAM budget goes.

~~~
z0mbie42
Electron hello world ~40MB of RAM

Qt with QML Hello World ~40MB of RAM

Gtk-rs hello world ~20MB of RAM

~~~
kelnos
Not sure where you're getting your numbers, but as a quick test I cloned an
Electron Hello World app[0], bumped its Electron dependency to the latest
version on npm, and ran it. It came in at around 90MB resident on the main
process, with a GPU process of about 70MB, a "zygote" process of around 60MB,
and a separate nodejs process around 35MB. Even if some memory was shared
between those, that's still quite a bit more than 40MB.

[0] [https://github.com/greggman/electron-hello-
world](https://github.com/greggman/electron-hello-world)

------
generichuman
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.

Has anyone tried this, any thoughts?

~~~
korm
Isn't the browser more bloated than Electron?

~~~
generichuman
I'm thinking of using the user's default browser, not downloading another one
for my program. In most cases the default browser is already running - no need
to launch another instance like electron.

~~~
shepmaster
By using the user's browser, you do have to handle all of the different
possible browsers _somehow_ , even if that's only to do annoying browser
detection and say "use a different browser". Electron and similar ideas at
least limit you to designing / developing / testing a single browser. At least
AFAIK; I haven't done any Electron work.

~~~
penagwin
I mean... it's no different than making any website work in multiple browsers.
Which really isn't too hard nowadays unless you're using bleeding-edge
features or obscure non-standard ones.

~~~
shepmaster
Supporting multiple browsers is always somewhat more difficult than just one
browser.

You are right that your choice of features plays into it, but I don't believe
that's all there is. Even in the best case (all of features you want are
available in all the browsers you care to support), you still should be
testing in those browsers (ideally on all of the platforms / devices you
support).

You also have to make the initial decision about what
browsers/platforms/devices you support in the first place, and then choose
when to re-evaluate your support. None of that is free.

Please don't get me wrong: I think it's a fine path (and one I have chosen
myself), but it's definitely not without downsides.

------
cosarara
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](https://github.com/cosarara/fucking-weeb)

~~~
throwaway8941
>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.

~~~
Crinus
Back when i was using iMac as my "watch" computer, i was simply changing the
text background color of whatever i was watching to green in Finder.

The feature to tag and color any file is really something that i miss in
Explorer (in Explorer you can edit tags if the file format supports it and
Explorer knows about it, but this only works for some file formats and even
then the UI is cumbersome).

~~~
kitsunesoba
The Finder’s color labeling feature has been useful for decades now, having
been around since the early 90s iterations of the Mac OS. I don’t know why
other file managers never picked it up; it deviates too far away from “Windows
Explorer clone” I guess?

------
rubyn00bie
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.

Just my two cents.

~~~
z0mbie42
Thank you for the "useful" feeeback :)

Maybe you can do your own so you can tell us the GiGa TrUtH about modern GUI
frameworks.

~~~
rubyn00bie
I said it was terrible and explained that your reasoning of "get shit done"
lacks any tangible meaning to the rest of the world. Don't be salty because I
posted my opinion, I didn't say you were a terrible person for writing it.

If you would've just titled your post "a review of electron, gtk, and qt for
making UIs with Rust" I'd have less of an issue. You also stated in another
post in this thread, and not in your article, that you feel "Slack" is
beautiful and that "beauty" was a necessity. That sounds like your principle
deciding factor; not, "get shit done."

There's lots of things you could have done, but the responsibility isn't on me
to coddle you through my thoughts. You could've just responded and qualified
"get shit done," and started a dialogue but alas... you decided to reply like
a child because you're upset. Maybe next time you shouldn't post to HN if
you're gonna let comments from random folks get you down.

~~~
z0mbie42
I just prefer actionable feedback rather than grunting.

As product developers we have the responsibility to create great product. One
of the criterion of a great product is beauty.

Get the shit done is just a summary of the previously mentioned criteria.

I would looove to be proven wrong that Electron, Qt and Gtk are not the only
viable options and would happily investigate further.

But I would also love to stop seeing random grunting from people who never had
written (or event tried to write) great Gui desktop applications. (I'm not
sayimg that you never have, I'm saying that by telling those are not the only
viable options you look like never have).

------
amelius
See also: [https://areweguiyet.com/](https://areweguiyet.com/)

------
dgellow
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.

~~~
jcelerier
> people commenting here seem to assume that the list is supposed to be an
> objective and complete comparison of GUIs

well yes, that's what you get for naming your blog like a research paper

------
leshow
How are you going to claim that Gtk doesn't have a 'responsive UI'? It's
native, it's very responsive.

Unless you mean 'responsive' like 'works on mobile'. Which seems kind of a
moot point considering we're talking about desktop applications.

~~~
anchpop
Responsive usually means it responds to changes in screen size by adjusting to
a nicer layout at that size (3 columns turning into 1, for example)

~~~
Crinus
IMO that is one of the most annoying misfeatures i've seen... on websites it
is practically always used to distinguish between mobile and desktop, which
misfires completely if you have a 1366x768 monitor and you aren't running a
fullscreen browser, whereas on desktop it is _always_ done because the
application is ignoring all the screen real estate it gets by padding
everything like balloons, using titanic font sizes (ignoring the system wide
settings for fonts and sizes, of course), etc.

In theory it should be applications automatically showing and hiding features
based on the available allocated area so that you could have (on desktop at
least) multiple applications visible at the same time and have a dynamic view
of their content's details just by resizing them. Which is a good idea.

In practice however it ends up as a band-aid for self-inflicted deficiencies.

------
z0mbie42
Hi, author here,

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
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.

------
kuriho
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.

~~~
raphlinus
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.

------
c-smile
Sciter/Rust ([https://github.com/sciter-sdk/rust-
sciter](https://github.com/sciter-sdk/rust-sciter)) was not tested:
[https://gitlab.com/z0mbie42/rust_gui_ecosystem_overview#not-...](https://gitlab.com/z0mbie42/rust_gui_ecosystem_overview#not-
tested)

but conclusion "The most promising seems to be Flutter" was made already :)

------
kodablah
> 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.

0 - [https://github.com/zserge/lorca](https://github.com/zserge/lorca) 1 -
[https://github.com/zserge/webview](https://github.com/zserge/webview) 2 -
[https://github.com/zserge/webview/tree/webview-x](https://github.com/zserge/webview/tree/webview-x)

~~~
baby
Isnt the only way to defend against dns rebinding to add authentication to
your local server?

~~~
kodablah
For these localhost-only servers, a simple check on Host is fine. E.g. if
you're on 127.0.0.1:3000, checking that Host is strictly 127.0.0.1:3000 or
localhost:3000 is good enough.

~~~
baby
Doesnt dns rebinding trick your browser into thinking this is indeed your
host?

~~~
kodablah
DNS rebinding involves changing your host's really-low-TTL A record to
127.0.0.1 (or other internal IP), and then on next request the browser will
then assume that's what the host is and make call to that new IP assuming
same-origin...but it sets the Host header as what the browser thinks
represents that IP. If it's not localhost or 127.0.0.1 (for this use case)
then we know someone tricked into thinking it was theirs that was our local
IP. So check the Host to make sure it isn't someone else's host "re-bound" to
your IP.

------
malkia
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).

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](https://news.ycombinator.com/item?id=20776848)

Thanks!

~~~
jcelerier
There is a nice improved docking system being developed for Qt by KDAB
(disclaimer: I work there) :
[https://github.com/KDAB/KDDockWidgets](https://github.com/KDAB/KDDockWidgets)

It closes the gap a fair bit with the VS docking system

------
todd3834
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.

~~~
c-smile
> Latest iteration is to write the majority of the app in Go and …

Check Sciter/Go : [https://github.com/sciter-sdk/go-
sciter](https://github.com/sciter-sdk/go-sciter)

It is used precisely that way: backend - Go, UI - Sciter.

------
billfruit
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.

~~~
simonh
The Mac had a brushed metal theme, used on some apps like Quicktime and
iTunes, since 1999.

------
ScottFree
No mention of imgui?

~~~
malkia
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.

~~~
ocornut
> being how to deal when you have lots of widgets and their state (e.g. the
> hidden state labeling)

Not sure exactly what you are referring you precisely? Happy to hear about it.
Once you get the hang of what the ID Stack is for, normally you would push on
the id stack for everyloop.

> I've found cases where the UI would lock, when flowing text

Never seen that sort of stuff happening.. if you do encounter issues of this
kind please try to report them with some details!

------
bvda
What are the ratings based on? What are the criteria to receive a ++ rating?

~~~
Narishma
It's completely subjective.

------
bla3
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.

------
sayusasugi
An Electron flame war seems inevitable. It's fine for quick cross platform
support but it absolutely screws over the user. QT is _far_ from perfect but
at least it's native.

~~~
sime2009
Is what sense is Qt "native"?

~~~
mynegation
In the sense that the executable is the machine code, not the Javascript
interpreter running through js files. In the sense that Electron is actually
native code (Chromium) running HTML UI and QT running its own custom-drawn UI,
both different from whatever platform-blessed UI toolkit is, no, QT is not
"native"

~~~
adev_
> QT running its own custom-drawn UI, both different from whatever platform-
> blessed UI toolkit is, no, QT is not "native"

Most Qt Apps are still using the widget layout in pure C++ ( from the stats of
the Qt company itself ) and do not contains a single line of JS or interpreted
language.

Then yes Qt is native and Electron is not.

------
buildzr
What exactly does "security" mean in this?

Difficulty of reverse engineering?

~~~
z0mbie42
Security means the global security of the framework.

Using electron exposes to some future chrome/Node CVEs and the past ones.

Qt on the other hand is used a lot in emdedd devices/automotive so we can
expect security being a top priority of the developers.

~~~
the_why_of_y
The reason why browsers have so many CVEs is that they routinely run untrusted
code; hence browser developers invest a lot of resources into sandboxing the
untrusted code and finding and fixing security holes in the sandbox and all of
the native code that is callable from within the sandbox.

For an Electron app, most of these CVEs are probably irrelevant, because the
code isn't untrusted in this case as it is bundled with the app already so
sandbox escape isn't an issue. (Similar arguments apply to Java with browser
plugins vs. "real" applications)

Native toolkits are never used directly from untrusted code; obviously this
means they won't have a CVE for sandbox escaping because there isn't a
sandbox.

But it also means they have a much smaller incentive to look for security
holes in their code. CVEs are security bugs that were found and fixed, and
number-of-CVEs is not an indication of how many unfixed security bugs remain.
While the attack surface is smaller if you don't run untrusted code, it
typically isn't zero, depending on what untrusted inputs a particular
application reads. I'd bet that some security relevant UB in a Qt image
decoder would take a lot longer to find than a similar bug in a browser's
image decoder, simply because of the incentives.

Example, try googling "browser security bounty", then try again with "qt
security bounty".

~~~
z0mbie42
Electron have CVEs which are not directly related to the browser:
[https://wickr.com/electron-vulnerability-the-quest-for-
cool](https://wickr.com/electron-vulnerability-the-quest-for-cool)

------
baybal2
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.

Same for Qt I think

~~~
IshKebab
Why would you want to do that? Isn't the point of Node that you get a powerful
GUI system but the tradeoff is that you have to use Javascript (or Typescript)
instead of a nicer language?

~~~
baybal2
??? What GUI system do you mean?

~~~
IshKebab
HTML & CSS (via Electron)

------
_pmf_
Tangential: does Chromium have a native widget abstraction? Are there any
projects that extract this layer and expose it?

~~~
scq
It does, called "Views". There's some documentation on it in the Chromium
codebase.
[https://chromium.googlesource.com/chromium/src/+/master/docs...](https://chromium.googlesource.com/chromium/src/+/master/docs/ui/views/overview.md)

------
hacker_9
Where is imgui bindings in this list?

