▲ 103 points
back
71 comments
The obvious answer is Qt but I also use wxWidgets[0] for projects with serious GUI requirements and Nuklear[1] or libui[2] for simpler ones.
[0] https://github.com/wxWidgets/wxWidgets
Yup, love Qt, have been using it since v. 4 for personal stuff, and in the past couple years worked on a cross-platform native GUI app that used Qt professionally.
I'd advise anyone using it to stay away from playing with the stylesheets to customize the look and feel of controls. If you do, you're in for a world of pain, and will shed blood and tears trying to get the app to look consistent and presentable across platforms. Given that cross-platform development is already hard as it is, you don't need that additional difficulty.
I did an app in wxWidgets a while back, and it was really frustrating how many things didn't work as expected: I spent more time wiring up windows to work correctly than actually coding the app.
I don't know if wxWidgets has gotten any better over the years, and I can't remember the specific details of the problems -- just that certain windows HAD to be parents of certain others in order for them to work, even though there was no obvious reason why this would be the case, and there was no documentation explaining this.
The other two look interesting, though. I'll keep those around for future reference.
I wrote a large wx python app or two in the day and did not have that particular problem.
I need to put in a warning about nuklear. As far as I can tell it has no documentation an is very difficult to get to work well in anything but the most trivial case. I put some work into it and came away very disappointed.
Two options that weren't mentioned were Nana and NanoGUI, which are both modern and under active development.
I use wxWidgets for Tarrasch, a chess GUI project I've been working on for years https://www.triplehappy.com. In general I am pretty happy with it. Largely it "just works" and I can do the things I expect to be able to do in the way I expect to be able to do them.
If QT had proper C# binding I'd be sold...
Have you tried Eto?
> I also don’t think that shoehorning web development technologies—which technically don’t provide any advantages over more traditional approaches—into desktop applications is a very sound idea either.
So, isn't sidestepping all of the problems author had with other technologies not an advantage enough? Not only that, using html/css for layout allows for easily created and very flexible responsive layouts which half of the other toolkits can't do at all out-of-the-box. Author seemingly swept this approach under the rug without ever seriously considering it ("I don’t have any personal experience using Light Table", "so developers can use hipster technologies like HTML, CSS and JavaScript", etc), and I can kind of see why he thinks that. But as a frequent user of such applications, I'm willing to take a slight performance hit if that allows me to use the same app on any platform, even if it's size becomes 200 megabytes bigger. Honestly, I'm a bit baffled why people are bothered so much by those 200 MB, it's not a burden to download it, it doesn't take much space on my ssd, or my RAM for that matter.
>I'm willing to take a slight performance hit if that allows me to use the same app on any platform, even if it's size becomes 200 megabytes bigger.
From personal exeprience, it's beyond slight perf hit. Often js apps are the ones hogging most of the resources on my system.
I don't think it's possible to emphasise this enough.
Slack and Spotify are consistently the worst-performing applications I use frequently, easily by an order of magnitude. Slack manages to absolutely tear through CPU cycles and battery life, while simultaneously being sluggish and shitty to use. Have you ever tried scrolling back in a channel? It's horrifying.
It's got bad enough that I've started to hack together native Mac clients for both in my spare time.
That 200M is nothing to you does not make it nothing to everyone. Some of us are working on Raspberry Pi or equivalent hardware, and every MB and Mhz counts.
I doubt amount of such users is substantial. I assume we are talking about business decisions here, and as far as those go ditching 0.1% of userbase to radically simplify development process and architecture is a pretty simple one.
The use of "hipster" as a pejorative doesn't even make sense to me here. HTML, CSS, and JavaScript are hipster technologies? They aren't new by any stretch.
Using this term seems like lazy authorship and thinking. Instead of explaining, just call it hipster and assume it's obvious.
Like you said, cross-platform support is the opposite of unimportant. The appeal of the web has a lot to do with the fact that a browser on any platform can (mostly) have the same experience without (too much) extra work. It may not be appropriate for Light Table, but a general hipster-like dismissal of web tech doesn't advance the argument.
This is a great deep-dive into the GUI approaches taken by some nice cross-platform apps, but the author seems to have decided early on to ignore web technologies. It would have been nice to see an Adobe UI broken down, or Spotify, or Steam. (It's not like their HTML/JS-based UIs look any whackier than some of those audio production apps!)
If you have infinite time and need infinitely great performance, writing your own GUI framework on top of each platform's native libraries is probably the way to go. But a huge team of people already built and bulletproofed one called Chromium. It's icky in some ways and abstracted far from the native layer, and it'll probably eat an extra 50ms when someone clicks a button, but you can build and ship a cross-platform app in less than three years. The docs are written, the bugs are known ones, and it's easy to hire people who can help you. Just saying :-)
(full disclosure: I worked on an Electron-based mail client—definitely biased :-) )
Are we looking at the same article? Chromium and Electron are very much mentioned, and the author clearly states their position on the topic.
I'll rephrase: Chromium is a browser. An extremely full-featured browser, made to support the monstrous complexity and the security minefield of 20+ years of web standards piled on top of each other, and an impressive feat of backwards-compatibility allowing us to view ancient websites as well as modern ones using a vast array of different technologies. Great work.
A lot of current laptops come with limited RAM and disk space.
In light of this, the idea of a Chromium-based tea timer seems a little disconnected with reality. Somehow people still do it.
My daily driver is an i5 Mac Mini, and I find the performance of the Spotify app to be almost unacceptable. Clicking on a playlist is sometimes quick, but sometimes takes 5 seconds or more for it to switch screens. The other day there was the VS Code cursor blinking fiasco[0].
I definitely appreciate the rapid development aspects of Electron. I've used it myself to build a couple of little one-off apps for specific purposes. But, man, I've got my mail client open 24/7, and if it's going to waste my battery life just sitting there, I'm not likely going to be using it for very long. And if it's laggy when I'm trying to quickly rip through my email...
Web technologies only works when the interface is the primary feature. Spotify is a music player, Steam is a game launcher. There isn't that much functionality under the hood. On the other hand if you only need performance, or functionality, something like Qt works. What's hard with "applications for professionals" is that you need both. I doubt Adobe mainly uses web technologies in their creative suite.
What I find a better alternative to Electron is to use the browser control of JavaFX (WebKit). You can program your UI in HTML/CSS/JS, and interact very easily with business logic written in Java, Scala, Clojure, Kotlin, Groovy, Ceylon, etc. (also JS, if you want). JavaFX comes included with the standard JVM. I imagine this approach will get even better with Java 9, especially the size of distributables.
In a world where all the apps are Electron based computers have no memory left and everything is subtly or outright sluggish.
My favorite cross-platform GUI toolkit ever was/is Cocotron:
Let's face it, macOS is the only desktop platform where users give a shit about whether apps look native and use system-provided controls. Mac is also the platform that has the nicest standard UI framework (Linux doesn't have one and Windows is forever haunted by Win32 despite Microsoft's 15 years of trying to push XAML).
Hence it makes sense to build desktop GUIs for Mac first, on the Mac, and cross-compile to other targets. Cocotron delivered just that: a minimalist BSD implementation of Foundation + AppKit, with a footprint light enough that you won't be ashamed to ship it as a DLL with your Windows app.
I've used Cocotron a couple of years ago for some custom graphics apps that needed to be deployed on Windows (one was a title creation app for a TV game show, just to design the graphics they needed for each weekly episode). It worked great. Even accounting for Cocotron's missing pieces and bugs, the UX of Cocoa-on-Windows was lightyears better than what people were used to when it comes to custom Windows apps.
Unfortunately Apple hasn't really made life easy for Cocotron because the platform has moved ahead so fast and Objective-C has accumulated tons of slightly warty features for Swift bridging.
The original OpenStep/Cocoa was clean, small and designed to be portable with light compiler support. Today, Apple APIs are a sprawling foundation for the iOS ecosystem, and it's in Apple's interest to keep making the API surface bigger and harder to port so that nobody can pull off what Microsoft tried with their iOS bridge [1]. (Obviously I don't blame Apple in any way, just feeling slightly nostalgic.)
[1] https://developer.microsoft.com/en-us/windows/bridges/ios
> Let's face it, macOS is the only desktop platform where users give a shit about whether apps look native and use system-provided controls.
Citation VERY MUCH needed. I'm on windows, and I care about applications using native widgets. I mostly care because non-native widgets tend to have horrible performance, but windows does have at least some consistent styles (there are several, but there is some consistency), and a lot of custom windowing libraries just look horrible, and more importantly, behave inconsistently.
I'll generally be willing to use odd-looking GUIs, but when you have an odd-looking GUI that has different behaviour then is standard, it really annoys the hell out of me.
For cross platform GUIs I use CAPI[1] from Lispworks, and was one of the main reasons I purchased it after using free Common Lisp implementations for many years. It's a well designed and stable system for building native guis on macOS, Windows, Linux, Solaris and others with a single code base and well worth the price of admission for creating desktop software.
Speaking of the lisp family... I don't know how it's implemented, but Racket has a cross-platform GUI story that, based on some of my cursory explorations, seems to be good. DrRacket is presumably built on it, and that's a non-trivial cross-platform app.
It looks excellent, and I love cl, but it's just too expensive.
These days there's also qtools which is pretty good.
For me, accessibility is important, too, which rules out immediate mode or canvas-based GUIs. And there are not just desktop, but web and mobile platforms. Like Nim, it would be nicer if there were a better language and framework designed with all this in mind. Elm and others don't seem to be it. Dojo toolkit was great at accessibility but I guess it is a bit out of date now. I know this may not be popular here, but Dart (and Flutter) might be the best option, at least for my needs.
I'm reasonably happy with (Py)Qt for my cross-platform file manager [1]. I didn't use Electron because its startup time is way too slow. I wrote a blog post about this choice, and which other GUI technologies I considered [2].
[1]: https://fman.io
[2]: https://fman.io/blog/picking-technologies-for-a-desktop-app-...
If you need to wish to keep it bloatless, there are still unfashionable ways to go, like Tk and Fltk.
Sadly fallen out of use and favour, but straightforward and battlehardened with a charming tendency to Just Work.
You don't even need to go that far. Qt and GTK are just as fast unless you are using a very underpowered system.
tk is so awesome. took me a while to grasp the auto resize things, but then you truly understand the genius of it.
I mentioned this a few days ago, but it's a shame he didn't look further into Java. NodeBox may or may not be slow but it isn't doing the same thing as the other apps, and like any GUI toolkit, it's easy for developers to make it slow.
Spine (http://esotericsoftware.com/) is a pro-level skeletal 2D animation app written in Java, though you wouldn't know it from the website. Judging from the videos of it in action it has no trouble doing high speed UI refreshes. Additionally there are lots of slick 60fps animations on Android written in Java too.
So whilst the article is interesting in a way, I do feel like he just blows off quite workable solutions for no better reason than a dubious extrapolation of a single app to all possible apps using that framework. Heck, he even says it looks nice - redraw speed was literally his only issue. Maybe it's just not using buffering very well?
I'm not sure about the difficulty of interfacing with Nim, but I've heard nothing but good things about the Lazarus IDE. It has visual layout tools, it compiles quickly and executables are reasonably small.
I'm having a hard time believing that re-drawing a UI 60 times per second would actually consume 100% of a CPU core. unless implemented in a way that causes spending too much time in the opengl driver (lots of pipeline state changes? extraneous drawcalls?) and making your program CPU bound. Seeing some code would be nice.
Also, you don't have to actually redraw the entire screen. You can use the stencil buffer to render only the parts that need to be updated (i.e. the UI pane).
Also, look into signed distance field technique for text rendering. Valve has a paper on it, look it up. My friend used it in his game, the text is scalable and looks great.
I've used nanovg and I'm not sure what the author is talking about. The text looks great and I've never seen it use a noticeable amount of CPU. Maybe he was doing UIs that were much more complicated, but the drawing is still being done by openGL, only the vector to triangle conversion is being done on the CPU as far as I know.
In the past I wrote a cross-platform (it supports iOS, Android, and more esotic platforms, like QNX, even on exotic architectures like MIPS) 2D vector graphics rendering engine that implements the Khronos OpenVG 1.1 API (that includes text rendering too). It's lightweight, comes with pure software and opengl/es back-end, closed-source and not free; but if you want to take a look just for fun, full functional evaluation builds are available here for download: http://www.amanithvg.com
Nobody mentioned Xamarin?
You can target Windows, macOS, Linux, iOS, Android.
i was very hopeful about that, but the toolchain just felt too immature on linux :( still keeping an interested eye on it.
FireMonkey is pretty good these days:
https://www.embarcadero.com/products/rad-studio
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/FireMonkey
But clearly targeting enterprise developers:
https://www.embarcadero.com/app-development-tools-store/rad-...
I have an old abandoned project inspired by ex widgets.... in assembly. Sometimes I think it might be worth getting back into it just for the GUI part as a lightweight framework, but assembly is so intimidating sometimes.
Honestly because of its package executable nature, I would probably try to do something in go instead.
That would be interesting to have a look at. I'm still yet to properly get into assembly myself, but there isn't enough graphical stuff done in asm out there.
This post is like a copy paste of this one: https://news.ycombinator.com/item?id=13952140
Other way around. This post was published first.
no mention of Adobe AIR which can build GUI app for desktop and mobile
for example: Balsamiq Mockups [0]
also tons of case studies [1]
[0]: https://balsamiq.com/products/mockups/ [1]: http://www.adobe.com/products/air/showcase.html
AIR doesn't run on Linux, which I believe was a requirement for the author.