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.
The Qt licencing situation is way more complicated than that. Parts of it are available under LGPL, parts are available under GPL, and some parts are only available under a commercial license which is a minimum of $5500/dev/year.
But all of the extras parts that are not under the LGPL are things that GTK (nor Electron) doesn't even have, so I would argue it's still an unfair comparison.
I am also baffled by the difference in license ratings. My guess is that some parts of Qt are licensed differently (like their WebAssembly port) and it's not immediately clear which parts are licensed under which license.
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 don't think this is very debatable. Consider the fact you might be in the vast minority of users.
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?
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)
I did say "non-technical", which is open to interpretation, but I did not mean 'computer illiterate' (i.e. only uses apps given by OS).
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)
> I did say "non-technical", which is open to interpretation, but I did not mean 'computer illiterate' (i.e. only uses apps given by OS).
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.
macOS is exactly where people expect native theme. People aren't using the apps you mention because they like the look of them. They're using them because they believe the functionality is better than the native-looking alternatives, or because they have no choice (e.g. with Slack).
"people" is "most users of the platform". A consistent native platform experience has been one of the cornerstones of macOS since even before OS X came along.
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.
In the native vs not-native look and feel discussion, I hold the opinion that different platforms have different answers. In MacOS, users expect a native look and feel, or at least something close to it.
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.
I heard about that a long time ago, back when it looked kind of dead. Glad to see it's still under development. I'm skeptical though, does it actually support all of Slack's features (or even a majority of them)? The screenshot is rather minimal, showing nothing in the way of unfurls, no formatting beyond a link and an @mention, no userlist, no channel info, no pinned messages, no reactions, etc.
I second the 'customization' label (though perhaps themability is a better one?), for me applications that do not use the desktop look and feel are a negative thing and something i try to avoid, so the 'look' is certainly subjective.
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.
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]
> The ability to create a native app which is at least beautiful as modern WebApps.
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.)
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:
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?
why are MacOS apps so damned beautiful and plentiful compared to linux and windows apps?
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.
> 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.
> This rings true to me as well, but why is this the case?
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.
I suspect a lot also has to do with the business opportunities available for developers on the different platforms. First of all, there is a near-limitless number of companies out there looking for Windows desktop developers to work on various inhouse apps.
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.
> "... why are MacOS apps so damned beautiful and plentiful compared to linux and windows apps?"
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.
> honestly the macOS app ecosystem is mostly running on fumes at this point
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 data, but there's no way that the Mac developer ecosystem is worse off than it was in the 00s."
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.
> 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.
You've not seen the Linux desktops of some of the guys in our Unix Ops department. If you're allergic to clutter, you'd have a seizure.
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.
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.
I think it's mainly the macOS widgets that look good, thus making it easy to build a good looking UI out of those components. You can't make a nice looking UI if the very building blocks you have to build that UI are ugly.
> 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.
> 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.
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 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.
What do you not like about Qt? Are the apps or the Widget themselves? The apps are the job of the developer to align and padd things properly. The wdidgets are designed to look as default platforms Widgets, so on Windows you get the buttons and progressbars to look native, in Linux it will use the theme you set. Where GTK apps by default look horrible, they do not use the platform icons and styles or dialog boxes, I assume the reason is that Qt is sold as a cross platform toolkit where GTK is a Red Hat project and RH is focused mainly on GNOME
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 also like the Win95 aesthetics, though last time i checked Gtk+ does support Windows' theme engine (not 100% perfect but 99.9% is there). At least Gtk+ 2 does, did that change with Gtk+ 3?
I would say that this is not objective at all; I find VS Code well designed but it doesnt fit with the rest of the Gnome desktop (or any desktop) at all, whereas fractal fits well with the rest of the gnome system, and in my opinion looks quite nice.
I’d say “modern” or “web-like” versus “traditional desktop”.
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.
A consistent look trains users to expect consistent behavior. For example, a native macOS table supports various modifier key behavior, arrow key navigation, type select, drag and drop, copy and pasting rows, etc. It's worth learning these features (the theory goes) because they translate across apps.
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.
For a long time I have hoped that the market would bifurcate, tablets and browser based devices for consumption and the modern equivalent of Sun SPARCstations for power users.
I for one am happy to see that apps include more and more features; I really did not like that I get 10 apps vs 1 for stuff that could be easily fit into one. My bank for instance keeps adding features all the time which allows me to do everything in the app without having to get the laptop out. I really wish more companies did that. You don't have to use it (and a lot of people would not even be able to find it) but for me it saves a lot of time.
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.
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.
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.
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.
The article seems to consider this hacky and insecure:
> 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?
My suggestion is to avoid cookies completely since they'd be shared with all services on the same IP/hostname because they ignore ports. I'd also add a random "key" as the first thing in the URL path so you'd end up with something like "http ://127.0.0.1 :1234/Lxk8gE7qnClf/actual/path/here" and have everything else tell the user to open the app with your icon or something.
This prevents malware from accessing your app while avoiding leaking authentication cookies to other http services on localhost.
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).
Consider the following task: you have UI widget and you will need to draw something on it. Something that cannot be trivially expressed by CSS means.
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].
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.
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:
I have. In my opinion it is actually much more secure than Electron since you rely on the browser directly. (And this is why I did it instead of using Electron.)
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.)
Yes and no - It likely has more extensions and stuff. But actually since electron is essentially chromium + nodejs I would guess electron would be "heavier".
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.
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.
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.
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.
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.
I suppose you could, but I think you'd need to write version detection for a browser, the ability to figure out the user's chosen browser, the logic to download a reasonable version of Chromium, install it, get it past virus scanners, etc.
Using the preinstalled vrowser would mean bloating you app with polyfiles to aupport all differents browsers. It's one of the reasons modern apps are bloated. Electron solves this.
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.
Alternative solution for keeping track of where you stopped watching series : watch them with mpv. If you quit with "Q" instead of "q", it will remember the position. Then, whenever you launch mpv, it checks if one of the files is in its list of positions (using absolute realpaths).
mpv series/*
Q
# continue from where I stopped
mpv series/*
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).
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?
I just use a text file for each series. Let's me also take notes about stuff I might forget due to really bad memory. Put a web or video link in there if relevant, too. If wanting less steps, search takes me right to name of the file if I wanted to do that.
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 then also have to remember what's the last episode I watched
... 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...
With default theming, GTK+2 looks like a bad ripoff of Windows 9x. (It's quite ugly, but not quite as bad as FLTK) GTK+3 has much better default theming.
Unfortunately there's still a lot of legacy apps out there, and others where the dev unfortunately picked GTK2 despite 3 being available. Not to mention some GTK3 apps not including the proper themes
GTK still has extreme padding and wasted screen real estate around texts, images, lists and other component. Making a slim version and better designed UIs would probably make a lot of difference.
On you typical laptop 14" FHD display, exactly this padding and sizing looks great (at @1x), while at 14" 1600x900 it still looks very good. Sure, on 1376x768 it looks terrible.
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 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.
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).
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.
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.
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.
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.
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.
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.
> 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!
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 far from perfect but at least it's native.
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"
> 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.
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".
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.
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?
Some people like working in javascript, or it's just what they know. I would agree, though, that it's hard to make an argument for JS in that context on its technical merit. Even with the power and universality of a browser rendering engine, I think JS on the desktop is a disappointingly hacky way to avoid investment in purpose built cross platform UI toolkits. (Either building better ones or hiring people who know how to use existing ones.)
#/media/File:Transmission_v2.92_on_macOS.png){kind=link}
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.