
Sad state of cross platform GUI frameworks - s9w
https://blog.royalsloth.eu/posts/sad-state-of-cross-platform-gui-frameworks
======
thomaszander
Its a great overall look, but I'd like to add some details to the Qt parts.

* he reviewed the QtWidget parts, and the designer for such. This is by now 15 years old tech that has not seen any new development for years. He didn't look at the QtQuick and QtComponents parts which people use now.

* He writes: «You can always buy a commercial license that gives you the rights to statically link your application but it comes with a hefty price.».

This seems an emotional conclusion. First, most people don't actually require
to statically link their apps. So this is only required for a small subset of
users. Shipping your app on mobile, for instance, can be done with the open
source version just fine. I think it helps to actually ask the sales team a
price instead of concluding it has a heafty price. Compared to visual studio
it actually is cheaper, last I checked...

* «Chart components are missing.»

Actually, there are several. Including 3rd party ones.

* he first states that QML allows one to use Javascript as a con, and then continues in his next line saying it is not nice to have to use C++. I think thats unfair. You can write your entire app in Javascript or C++. You can mix them. Your choice. This are add-ons. Like NPM can be seen as a bunch of add-ons to Node. Complaining about the ecosystem being diverse doesn't really sound like a negative to me...

------
s9w
> QT website is one big clusterfuck of corporate bullshit and hard to find
> stuff. They keep redesigning it and every year its getting worse and worse

That captures my own impression accurately

~~~
thomaszander
I would fully agree about their main website :)

but, yeah, its a website they use to sell stuff. Advertisements tend to work
better if they don't get stale.

On the other hand, the doc.* website (its on its own sub-domain) is almost
boring and just entirely functional. And that is what techies actually use.

------
_bxg1
I think the vitriol against JavaScript is unfair, but I absolutely agree that
if native cross-platform desktop development weren't so horrendous, many
things that currently use Electron, wouldn't. The web's main draw these days
is that it's a free, cross-platform GUI platform that sees _active development
and community support_. That's the bar.

All of that said - and I've said this elsewhere before - _JavaScript is not
the problem with Electron._ I'm so weary of hearing this. Even the web is not
really the problem with Electron. Electron's problem is that there's no way to
share Chromium instances across installations or processes. _That 's it_.

~~~
giulianob
It's both. Go look at your memory usage per tab and it's not uncommon to see
hundreds of megabytes for a simple static 2d UI. The way web renders is
extremely inefficient then you couple that with a language that has no regards
for how a computer actually works and you get to the sad state we're in today.

~~~
_bxg1
> hundreds of megabytes for a simple static 2d UI

Without a specific example that's hard to argue against, but I would wager it
has more to do with images, unnecessarily complex DOM, and possibly just poor
engineering, as opposed to JavaScript itself.

> that has no regards for how a computer actually works

You mean like Python? And Lisp? If you're taking issue with the very concept
of high-level languages then state it as such, and good luck making a case for
that.

------
giulianob
I recently went through this exercise and it really is sad. I actually decided
to use the Godot game engine because at the end of the day it's fairly
lightweight, you're in complete control over the rendering, the built in
components are great (the editor itself is written in the game engine), it
supports C#/C++, it runs literally everywhere, and it's completely free/open
source.

I'm keeping my eye on Flutter and Avalonia as well but so far Godot seems the
most mature on the desktop.

~~~
_bxg1
It's fascinating that a whole game engine ended up being the right solution.
Although, I guess I have heard of people doing the same with Unity. And I've
heard good things about Godot as a project in general.

FWIW here's one more relevant option that popped up earlier today:
[https://news.ycombinator.com/item?id=22766639](https://news.ycombinator.com/item?id=22766639)
It looks pretty Flutter-like.

------
lubonay
Flutter _may_ deliver, but Google has this nasty habit of killing projects
right after you personally buy into them.

------
gyrgtyn
> I can’t quite figure it out, why do people prefer writing Electron apps as
> opposed of having a thin backend layer that communicates with the frontend
> in the user’s existing browser via websockets or long polling or whatever.

that's not possible. For one thing, you need https.

~~~
Supermancho
A one-and-done installer for an existing browser is too sandboxed to work as
he describes, afaik.

If you ran local code and added some plugins with permissions, it would be
possible, maybe.

------
mixmastamyk
Interesting that the author understandably hates on C++, mentions Python
bindings but then never appears to try them. It is true often cross-language
docs are not great, but is pretty easy to convert between the two languages
with a few examples.

Also, I'd never heard of the limit of LGPL on static-linking. I have a few
pure Python projects under this but don't think the rule applies.

------
java-man
Missing from the list: java swing. Of course, it is missing latest eye candy
features like shadows, but otherwise it's rock solid.

~~~
RandyRanderson
Having developed in Java for many years now, primarily on Windows for the
desktop, Linux for the server side, the occasional MacOS desktop and even
Android and Android Wear, I'm very rarely reminded that there are differences
in platforms.

The biggest issues I've faced:

* On a headless server you can't load any GUI components (mostly my mistakes).

* Android is still effectively Java7. I blame Oracle and Google for this.

I've even recently moved from Java 7 to Java 11 with very little issue.

I'd be interested in people's thoughts about why "new is better"? My own take:
you can't sell tools, tutorials, books, conference tickets, etc for something
that just works and is well documented with great IDE support.

~~~
java-man
In the context, I take it the question is about why javafx is better than
swing?

I would say javafx produces better eye candy, and the programming model is
much better in terms of properties and bindings (not that one can't
reimplement a similar framework in swing, but in javafx it is just there).

I feel javafx is still lacking in many areas:

\- focus handling is still buggy: one can have multiple nodes having focus and
accepting keyboard input

\- WebView behavior differs a lot between 8/9/10/11

\- mouse subsystem has critical issues on linux

I wish javafx got more support from Oracle, but we know that neither Sun nor
Oracle viewed the desktop as high priority. I don't think the situation will
change, considering the fact that the majority of development switched to
browser-based js.

------
TurboHaskal
So, if you don't mind dropping some cash...

\- Delphi is great if you have a Windows machine and is still quite popular in
Europe if you _really_ want to make a career out of it.

\- Xojo is extremely well priced. I cannot say much about it but a friend that
is a former Lazarus programmer swears by it.

\- LispWorks CAPI is hands-down the best I've tried, but requires individual
licenses for each platform and if you want 64bit you'll be breaking the bank.

> Pascal is showing its age and feels a bit wonky in comparison to C like
> languages.

What makes Pascal show its age? Proper records? Generics? :)

~~~
badsectoracula
> a friend that is a former Lazarus programmer swears by it.

I'm not sure swearing evokes much confidence :-P

I've only tried the demo version of Xojo a couple of times but i found its
design to be _very_ macOS oriented. The GUI does work in Windows and Linux
(and actually i've tried it on both of these systems instead of macOS) but
pretty much everything about the layout and design feels macOS-y.

------
cocoa19
I have written multiple applications with Qt, GTK, JavaFX and your blog post
is spot on, on everything I read.

This is a very high quality post. It shows you really worked on learning the
frameworks, as opposed to writing a superficial post after 1 hour of playing
around with a framework.

------
pkphilip
Other interesting cross platform IDEs include imgui when used with Nim. This
is remarkably easy to use
[https://github.com/nimgl/imgui](https://github.com/nimgl/imgui)

------
arkanciscan
Never seen a cross platform gui that I'd rather use than a website.

~~~
ScottFree
Imagine you have seen a cross platform gui that you'd rather use over a
website. What would it look like?

~~~
pdamoc
Something like Elm but that compiles to native binaries. It should come with
Material Design level of HIG documentation and a tone of examples. The
compiler and the Native/Kernel parts should be implemented in a modern systems
programming language, maybe rust.

~~~
ScottFree
Why elm? It looks more like a DSL than a real language and a verbose one at
that. I'm looking at some of these examples on their website, like the random
number generator, and wondering why it takes so much code to print a random
number to the screen.

------
j88439h84
Beeware makes native guis on all platforms, android will be ready soon.

