
Cross-platform GUI Toolkit Trainwreck, 2016 Edition - dgellow
http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trainwreck-2016-edition/
======
jakobdabo
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](https://github.com/wxWidgets/wxWidgets)

[1] [https://github.com/vurtun/nuklear](https://github.com/vurtun/nuklear)

[2] [https://github.com/andlabs/libui](https://github.com/andlabs/libui)

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

~~~
mixmastamyk
I wrote a large wx python app or two in the day and did not have that
particular problem.

~~~
SomeCallMeTim
Good to know. They may have cleaned things up.

Or maybe I was doing something weird. For some reason the projects I'm trying
to accomplish always seem to be the thing the library designer didn't
anticipate. :|

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

~~~
yjftsjthsd-h
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.

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

~~~
thomastjeffery
> I doubt amount of such users is substantial

"So screw them. We don't care about their concerns."

This is not a solution. Sure, the majority of users don't care about the
performance hit, or size requirement, but solving that problem in a way
substantial enough to make those with tighter requirements happy _can only
help everyone_.

I have an 8-core 4ghz CPU, 2 >5tflops GPUs and am _not_ content with the
performance of web-based GUI. It's sluggish and bloated. No matter how
powerful my system is, _I can tell_ , and it's enough of an issue to warrant
complaint.

~~~
iaml
Problem is, as author stated there is no such solution right now. It's all
about trade offs and in any case you got to sacrifice _something_. Sure,
solving this problem would be amazing and good for all but I know I'm not up
to task and there are tons of other people much smarter than me who tried and
failed already. I don't think electron is the problem, I just think there are
some quirks with it that were not yet ironed out.

~~~
thomastjeffery
> I don't think electron is the problem, I just think there are some quirks
> with it that were not yet ironed out.

The problem with electron is not that it has quirks, but that it is chromium
"ironed out" to be a GUI toolkit. It's effective, and generally well done,
considering that fact, but will continue to be noticeably sluggish as long as
it even resembles what it was in the first place.

------
bengotow
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
:-) )

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

~~~
ta34534445
Horses for courses.

If you're writing a tea timer perhaps chromium isn't the right tool for the
job. I'd certainly be the first to agree and the author highlights this too.
If your tiny application doesn't add much functionality, I'd even suggest that
a multi platform solution isn't necessary.

However, if you are writing a full featured desktop application, it starts to
become a sensible option.

------
pavlov
My favorite cross-platform GUI toolkit ever was/is Cocotron:

[http://cocotron.org](http://cocotron.org)

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](https://developer.microsoft.com/en-
us/windows/bridges/ios)

~~~
fake-name
> 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.

~~~
mikewhy
The right-click menu is a different style between the desktop and the title
bar. Right out the gate there are so many inconsistencies in Windows I can
really see where the person you're replying to is coming from.

~~~
iaml
Case in point, if you want to change some setting in w10 you may want to look
in one of the following locations: Control panel (1), Control panel (2),
Registry, Group Policy Editor, some random menu or other program you need to
launch. Really screams "consistency" doesn't it?

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

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

[1]
[http://www.lispworks.com/products/capi.html](http://www.lispworks.com/products/capi.html)

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

[http://docs.racket-lang.org/gui/index.html](http://docs.racket-
lang.org/gui/index.html)

~~~
shakna
Racket seems to utilize GTK under-the-hood, which has a terrible accessibility
story.

~~~
mushiake
Racket uses cocoa for macos, win32 for windows, gtk+ for linux. But it is
really minimal and you may find feature lacking.

~~~
soegaard
For anyone interested in how Racket (Matthew Flatt) pulled it off :
[http://blog.racket-lang.org/2010/12/rebuilding-rackets-
graph...](http://blog.racket-lang.org/2010/12/rebuilding-rackets-graphics-
layer.html)

------
mherrmann
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](https://fman.io)

[2]: [https://fman.io/blog/picking-technologies-for-a-desktop-
app-...](https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/)

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

~~~
thomastjeffery
You don't even need to go that far. Qt and GTK are just as fast unless you are
using a _very_ underpowered system.

~~~
CyberDildonics
fltk is orders of magnitude less bloated than either of those.

~~~
thomastjeffery
It certainly is. When I run it on a system from >10 years ago, I can
definitely tell the difference. With the systems I use now, however, the
difference is a negligible one.

------
zigzigzag
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/](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?

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

[http://www.lazarus-ide.org/](http://www.lazarus-ide.org/)

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

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

------
mfabbri77
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](http://www.amanithvg.com)

------
dgellow
Nobody mentioned Xamarin? You can target Windows, macOS, Linux, iOS, Android.

[https://www.xamarin.com/platform](https://www.xamarin.com/platform)

~~~
zem
i was very hopeful about that, but the toolchain just felt too immature on
linux :( still keeping an interested eye on it.

------
clouddrover
FireMonkey is pretty good these days:

[https://www.embarcadero.com/products/rad-
studio](https://www.embarcadero.com/products/rad-studio)

[http://docwiki.embarcadero.com/RADStudio/Tokyo/en/FireMonkey](http://docwiki.embarcadero.com/RADStudio/Tokyo/en/FireMonkey)

~~~
T-A
But clearly targeting enterprise developers:

[https://www.embarcadero.com/app-development-tools-
store/rad-...](https://www.embarcadero.com/app-development-tools-store/rad-
studio)

~~~
nenadst
if you only take Delphi the price is a little bit better (still not great)
[https://www.embarcadero.com/app-development-tools-
store/delp...](https://www.embarcadero.com/app-development-tools-store/delphi)

and there is not Linux version of FMX either, they just released Linux-Server-
only (e.g. apache modules etc) support, for which you have to buy the
enterprise version (ugh)

but you _can_ create Android, IOS and macOS Apps with it
[https://www.embarcadero.com/docs/rad-studio-feature-
matrix.p...](https://www.embarcadero.com/docs/rad-studio-feature-matrix.pdf)

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

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

------
ekvintroj
This post is like a copy paste of this one:
[https://news.ycombinator.com/item?id=13952140](https://news.ycombinator.com/item?id=13952140)

~~~
sdflkd
Other way around. This post was published first.

------
zwetan
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/](https://balsamiq.com/products/mockups/)
[1]:
[http://www.adobe.com/products/air/showcase.html](http://www.adobe.com/products/air/showcase.html)

~~~
rspeer
AIR doesn't run on Linux, which I believe was a requirement for the author.

~~~
zwetan
Adobe AIR 2.6 does run on Linux

~~~
rspeer
"Supported distributions include Fedora Core 11, Ubuntu 9.04 and OpenSuSe
11.1." And you have to install a ton of 32-bit dependencies.

This is abandoned and insecure. A Linux user would only do this if they were
desperate to run an AIR app and were willing to compromise the integrity of
their system to do so.

