Rust GUI ecosystem overview
gitlab.com
gitlab.com
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.
There's a big chart here:
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.
That is a very debatable assumption. The large majority of apps I use use the desktop's native theme.
I'm a dev/technical user, in the key audience for native look & feel powertools, yet the main apps I use on Mac are still Chrome, Spotify, Slack, VS Code. None of these use the desktop's native theme.
Imagine the case for non-technical users.
Average users expect apps to have a custom look and feel. Ever tried SnapChat?
... no
> Imagine the case for non-technical users.
Most non-technical users I know - elderly couples, family, etc don't even install apps, they just use what their OS gives them. I don't know any who does not have VLC or LibreOffice however (but that may be a french thing)
The discussion here is really about average users, and the baseline assumption here is that we are talking about apps that don't come with the OS, that we'd install, since we're devs, creating new stuff.
> I don't know any who does not have VLC or LibreOffice however [...] (but that may be a french thing)
It's a French or power-user thing.
I was about to say "you know that the median mobile-device user has one third-party app installed, right?" but then I thought better and Googled it first. This used to be true, but the stat is far out-of-date; nowadays the median mobile-device user has 40-to-80 apps!
I'm kind of shocked how much user behavior has changed, honestly.
And I also thought about Snapchat as a reference for end user application.
Certainly because it's a model of simplicity and is really far from native themes.
Who are 'people' here? The strawman here is that 'average users' do not expect native theme.
If you ask most people, they probably won't know to identify this as a desirable trait, but what they do know is that if they launch a non-native app it will likely not look or behave according to their expectations. For example, I'm an expert user and even I'm still tripped up by the fact that Slack has a rather anemic menubar, and Discourse's is even worse.
Windows, Linux and Android users have no such expectations. In fact, in the case of Android, a non-native look and feel could be considered a positive thing since the native android look and feel is kind of terrible.
Or because they are unaware that there are native apps available, just from third parties. For example: https://volt-app.com/
What? In my dictionary, screenshots of "modern webapps" appear when I search the definition of the word "ugly".
[0]: https://stripe.com [1]: https://www.figma.com
I don't consider this desirable or even a reasonable criterion. I want my desktop apps to all use the same toolkit and look consistent. Unless you make a bog-simple app, something like Electron is never going to give you that. With Qt/Gtk/etc. you can certainly make custom widgets if you have special-purpose needs. For someone who comes from a web development background, there's going to be a learning curve for that, of course. But experienced Qt/Gtk developers should not find it meaningfully more difficult.
> e.g. Slack or VS Code (Electron) are beautiful, while fractal or notecase (gtk) are not.
That's incredibly subjective, and I don't agree with it. I think Slack and VS Code are fine looking apps, but I wouldn't rate them meaningfully higher than all the Gtk apps running on my desktop right now. (And regardless, I value consistency over some ill-defined measure of "beauty" when it comes to UI.)
Also, In the analysis I tested Qt with QML, not widgets.
Note that the apps above are not implemented with Qt or Electron either, they use the official Apple frameworks.
One is developer culture. Going all the way back to the earliest Macintosh days, Apple has always had detailed guidelines about how the one true way a GUI app should look and feel. And the importance of following those guidelines gets drilled into you from your very first Hello World program. This leads to all apps on macs to look both good and consistent, giving developers a lot of inspiration to draw from when they write their own apps. Windows and Linux simply doesn't have this culture ingrained into its developers. It also helps that Apple really only has one GUI framework at a time that it pours all their effort and focus into while Windows and Linux always have at least 2 or 3 competing frameworks that never get quite the attention they need.
Another might simply be financial incentives. Anecdotally Mac user care more about what their apps look like than Windows and Linux users, thus the financial incentives to put in the effort to add the final polish to your apps is higher, since it probably affects sales much more than it does on Linux and Windows. Also (and equally anecdotally) Apple users seem far more willing to pay for small useful applications from indie developers so more indie developers put more effort into producing small useful and beautiful apps for Mac.
This rings true to me as well, but why is this the case? If we roughly assume that Mac users are 1 order of magnitude fewer than Windows users, they must be >1 OOM more likely to pay for these kinds of apps to generate this impression.
I struggled with this puzzle for quite a while when I switched from Mac to Windows. Utilities are simply not comparable, either in design, functionality, or simple quantity, for a market which is (on paper) both much larger and much older (if you restrict your view to the OS X era).
As an aside, it totally makes sense to me why Linux utilities are numerous and awesome, but have (usually) poor graphic design, because that Bauhaus-esque function over form describes how I prefer to work, too.
Because the Apple macOS ecosystem already has an coherent design at the point where I (as a macOS user) would hate to bring another app that breaks the coherence.
Also Apple's official apps are generally much better than the MS ones or Gnome ones (see IE vs Safari) which makes the expectation of users higher.
IMO Apple really made a great, healthy ecosystem around the macOS.
Secondly, there is a lot more money in the business and specialist app market for Windows. I worked for 3 years at a company developing a Windows application. We charged $5k a year for a license plus a good 50-500 consulting hours to adapt the application to our customers business. That was a solid business targeting a niche market, and there are countless companies like that around in the Windows space. Those opportunities don't really exist for Mac developers. Most people specializing in Windows desktop development end up working on stuff like that if they don't end up at Microsoft/Adobe/Autodesk etc.
If I was to start a company trying to develop desktop applications for Windows there is no doubt I would target business customers willing to pay $1k-10k rather than trying to sell $10-100 to consumers. If I was targeting Mac users I would probably target the $10-100 consumer space.
While that was the case ten years ago, honestly the macOS app ecosystem is mostly running on fumes at this point. There's few people coming into AppKit development, and iOS developers seem to have an irrational fear of putting any effort into learning the desktop paradigm even though the API is largely the same.
Apple is making half-hearted efforts to fix this problem by introducing two new GUI APIs on the Mac. "Catalyst" is a porting layer that lets you put iPad apps on the Mac desktop. The look'n'feel of these apps is pretty much as clunky as you'd expect. Then there's "SwiftUI" which is a new React-like runtime that spans all Apple platforms. SwiftUI is in its early stages and will take years to catch up with AppKit's functionality.
At this point Mac desktop development is effectively in a limbo: no one wants to start new AppKit projects because Apple is strongly implying that it's deprecated (although they don't seem to know exactly what it's being replaced with). So it's pretty much Electron or Qt on the Mac now, unfortunately. As an AppKit developer since 2002, it breaks my heart a bit.
I don't have data, but there's no way that the Mac developer ecosystem is worse off than it was in the 00s. There's significantly more Mac users now, and there's orders of magnitude more developers with experience developing for Apple platforms.
Maybe most devs won't venture outside of iOS to try Mac development, but 10 years ago the few long-time Mac devs were (by necessity) putting their Mac projects on hold to work on iPhone apps.
> because Apple is strongly implying that it's deprecated
Lots of iOS developers are writing blog posts claiming things like this, but every single Apple app on the Mac is written using AppKit. You can't deprecate the technology behind your entire platform.
Maybe 15 years from now SwiftUI will have replaced AppKit as the dominant way to write UI code on the Mac, but generations of apps will be born and die between now and then.
I don't have hard data either. But ask any old Mac developer on Twitter whether they're doing better now than ten years ago, and I bet a majority would disagree.
For one thing, the rise of mobile app stores has destroyed the perceived value of software. A $50 app now seems very expensive to most, whereas it was mid-priced back in 2008. Yet the Mac App Store has failed to bring in the mass audience that would compensate for the lower unit prices.
Not sure it has much to do with the developers at all.
Harsh but fair. I keep thinking that if we just make good app development easier, we could bring some of those well designed apps back to the native desktop instead of losing them all to the web. The reality, as you pointed out, is that the underlying technology is irrelevant. This is a marketing issue.
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.
I can't criticize. I paid for every square inch of the screen of my 27" iMac at home, and darn it, I'm going to put something on every last one of them.
I've found the former to be quite true, though QT comes close. I actually quite like ObjectiveC, but Swift is clearly superior and has had great uptake in the iOS/macOS community.
i.e. Transmission uses GTK3 and looks like this[1] on OSX.
[1] https://en.wikipedia.org/wiki/Transmission_(BitTorrent_clien...
> A native Mac OS X GUI application
> GTK+ and Qt GUI applications for Linux, BSD, etc.
GTK3 in general looks a hell of a lot nicer than GTK2 but now I can't think of any GTK3 applications that actually run on OSX...
But there are more attractive apps that use GTK. They just have spent time doing custom themes.
It’s not quite objective but I agree you’d probably find 90 or 99% of respondents prefer the web look for desktop apps.
The time when desktop apps looked like a consistent toolkit is gone. Now it’s more important for a desktop app to look like its own web version than to look like the next desktop app.
But every web app is a snowflake, so there's no shared expertise to be developed. I don't expect anything beyond point and click. We've given up on empowering users.
That's because the mass market doesn't want to be empowered. They want to consume.
That said, phones and tablets are custom built for those people. The only people still using laptops and desktops are people who need to get things done. It's beyond time for desktop OS's and apps to start focusing on the power user again.
That's wrong.
QML has two mode: one "interpreted" ( the javascript-esque) and one that can be compiled to native C++ without js.
And WebKit / webview itself is a plugin for Qt, it is absolutely not required.
... that is entirely false. Qt has its own scene graph renderer which has nothing to do with WebKit.
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.
For a GUI app, business logic is usually not where your RAM budget goes.
Qt with QML Hello World ~40MB of RAM
Gtk-rs hello world ~20MB of RAM
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?
It also supports a super bloat-free option where entire Desktop Apps can be run from Gists. All Apps are run and share the same executable (and re-use its dependencies) so the Gists only need to contain their App-specific scripts and dependencies, giving each App tiny footprints:
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.
Anyway the reason this would be desirable is because the user's browser is likely already open (and doesn't have to be chrome), and one of the critiques with electron is that each electron app is essentially another instance of chromium running, they don't share any resources.
But a web browser that's already open just has to open a new tab, and you can close it when you don't need it, allowing the otherwise lightweight daemon to run with minimum performance impact.
> Web broswer communicating with a Rust local server: too much hacky, insecure? (DNS rebinding attacks) and does not support native features like tray icons.
Personally I don't agree it's hacky and while DNS rebinding attacks are feasible, doesn't your application just need to check against a host whitelist to protect itself?
I hadn't considered the security part yet, to be honest. I'm open to suggestions for methods to make sure the application is secure.
It at least used to be the case that this could be gotten around with flash, though that may be fixed, and many people won't run strange flash anymore anyway.
Another way, if you're using WebSockets, you can establish that the latency is unrealistically low to be a switched physical network, with pings (with cookies).
This prevents malware from accessing your app while avoiding leaking authentication cookies to other http services on localhost.
Security wise, that is.
I enjoy noticing the system tray spin on cue when I boot up a laptop or plug a phone in as it syncs over WLAN. It's quite a cool feeling seeing the automatic file sync through the air as if by magic, no separate Dropbox/Google/Onedrive/Nextcloud service needed.
I can't do that with only Syncthing on Windows.
You do have to add authentication to prevent against dns rebinding but I solved that by adding a random token in the get parameters when I launch the page. (You then cache this inside a cookie.)
What will you do in native application?
You will put custom drawing code (C/C++/Rust/Go) in WM_PAINT/onPaint/onDraw method of the widget. If in Sciter[1] then you can do event_handler::handle_draw(graphics* pgfx) - Sciter's applications are native ones.
This will be fastest and most lightweight way of doing such things.
Now, what will you do on Web platform (browser or Electron)?
Calling server (over TCP - browser, RPC - Electron) for providing a drawing is clearly not an option.
So you will make some <canvas> element where you will draw that thing. <canvas> is a bitmap based thing so you will have that bitmap allocated as in CPU memory as in GPU memory. Plus you will have some nontrivial setup to position that <canvas> where you need it.
Therefore you will have at least memory requirement increased for your app (if to compare with native/sciter app).
Note that modern browser uses separate process for each tab. So you will have at least 3 processes running your application. That's also about memory and CPU consumption needed for RPC between them all.
And what if that thing that you will need to draw is not that trivial - will be heavy for script to handle...
And so you will start to add JIT to your script engine. That will need more memory and CPU (at least for bootstrap). Otherwise some smart people will propose you to use WebAssemble for that, so you will load WebAsm VM into your application...
See where it goes?
To create obstacles for yourself to overcome them heroically, right?
If that is for you personally then you can do whatever you want. But you want to put that burden to your users ... And so as many users as many machines converting that needles payload to heat without doing anything extra of what native applications can do already …
To a state where users need a (another) datacenter to access/view/use even trivial apps with “reasonable” responsiveness. There are services already being offered to this end [1].
Both? Mostly the former? Largely the latter (depending on plattform)?
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.
mpv series/*
Q
# continue from where I stopped
mpv series/*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).
... I generally just look in the "recent files" menu of my mediaplayer ? Also, many players are able to remember the last position in a file so if you open a file and are at the end...
Simple, text editors been helping me solve problems since EDIT on MS-DOS. No reason to learn something more complicated. The method is cross-platform, too. :)
I also heard that the API have some misfit with Rust ownership model: https://news.ycombinator.com/item?id=20368618
Just my two cents.
Maybe you can do your own so you can tell us the GiGa TrUtH about modern GUI frameworks.
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.
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).
well yes, that's what you get for naming your blog like a research paper
Unless you mean 'responsive' like 'works on mobile'. Which seems kind of a moot point considering we're talking about desktop applications.
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.
It's useful because we see more and more 'convergent devices' like the librem 5, pr a raspberry pi with a 10' screen
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.
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.
If it's still dismissed in six months to a year, that would be sad.
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.
but conclusion "The most promising seems to be Flutter" was made already :)
> 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
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!
It closes the gap a fair bit with the VS docking system
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.
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.
Check Sciter/Go : https://github.com/sciter-sdk/go-sciter
It is used precisely that way: backend - Go, UI - Sciter.
https://github.com/Gekkio/imgui-rs
And nuklear (another imgui library)
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.
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!
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.
Difficulty of reverse engineering?
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.
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".
Same for Qt I think
0 - https://github.com/cretz/qt_cef_poc 1 - https://github.com/cretz/rust-qt_cef_poc