Ask HN: What's the best library for making cross-platform UIs?

SWT rarely gets any love in desktop UI threads around here, but I recently wrote a small desktop program using SWT and Java and found it to be a reasonably pleasant experience. The main purpose of the program was to allow the user to view a couple of database tables, and using a tree view widget with columns was a key requirement. SWT is the widget toolkit used by Eclipse and is mostly native, using GTK on Linux, Cocoa on macOS and the Win32 API on Windows. It is still in active development, and support for HiDpi was recently added.

I started off with an Angular 1 app using Dropwizard for the backend. But I was frustrated with (1) the incidental complexity needed to use a decent tree view widget with sorting, filtering, pagination, etc. and (2) the slow response time of having to go from the web page, to the backend server, to the database and then back again.

Around that time, I ran across a Java Swing app written by another group and was surprised about how fast it was to start up and to access and display info from a database. Since it used Swing though, the fonts under Red Hat 6 were terrible. Since I already had most of the "business logic" in Java, it was straightforward to quickly prototype a viewer using the SWT/JFace tree viewer. It was fast to start up, and the fonts looked decent since it was using native GTK2. I dropped the Angular stuff and coded the program in SWT and it has been well received by my coworkers.

I'm a big believer in using native widgets to the extent possible, which SWT does. For the tree view widget, for example, it uses GTKTreeView for Linux and NSOutlineView for macOS. For Win32, there is not a native tree view widget with columns; SWT uses the native Tree widget and draws the columns itself. Qt on the other hand emulates a treeview widget on macOS for example and does not use NSOutlineView.

There is occasionally a least-common-denominator issue when using SWT. For example, I wanted to use tab widgets that have close buttons on the tab like web browsers do. The native Win32 and Cocoa tab controls do not provide for close buttons, so I had to use an SWT provided tab widget that is not native at all. Doesn't look great, especially on the Mac, but it's fine.

The SWT API is dated, as it comes from the early 2000's, but it seems straightforward and I rarely find myself surprised. Getting the GridLayout to do what I wanted was probably the trickiest part. There are examples to follow on the web. It does not have the kitchen sink aspect that Qt and WxWidgets have, since Java is there to provide the networking and database access, etc. Java 8 cleans up a lot of the issues with having to use anonymous inner classes everywhere in favor of lambdas, and if Java is not your cup of coffee then SWT is usable from other JVM languages.

Deploying the program works ok. For macOS and Windows, I package it up with its own JRE. I do face the issue of the best way for end users to update the program easily. I haven't found an easy to use update package like Sparkle on macOS that works for cross desktop platform Java apps. I'm contemplating turning my program in to a full Eclipse RCP program to take advantage of that framework's built in update facility, but the learning curve seems daunting. And I'm a big fan of Intellij IDEA for Java development, and don't want to use Eclipse. :-)

The best one I know is html 5

Tk is antiquated (no antialiasing [1]) and has a poor look on Linux. It lacks functionality in widgets such as embedding a progressbar in a tree/list (don't remember) widget, which Qt supports. Also, poor font rendering support. (doesn't render Devanagari and probably CJK scripts). It feels like a 10 year old tech which it is.

(1) Maybe there is some option for it somewhere, but if so, having antialiasing disabled by default is weird.

My vote is for electron, although I'm following how React Native develops really closely. From what I've seen, the best new "Desktop" apps tend to be built with electron. We've been using it in production and, despite having to make pull requests for framework-level bugs fairly regularly, we've haad a pretty good experience overall, and far better than anything else we've tried - although, as I said, we have yet to seriously look into React Native. Also, by cross-platform I'm assuming you mean OS X, Windows, and Linux. If you also want to include mobile, then there are so few options there's no longer any real reason to debate.

I just started using it a few months ago, and perhaps the antiquated API you refer is the "old methods" described in wxWidgets books and such. There is a new modern-ish API with jQuery like function chaining, and an Advanced UI (AUI) subsystem enabling one complete control to the presentation layer. It is not perfect, but I'm liking it.