Sad state of cross platform GUI frameworks | Hacker News Reader

Sad state of cross platform GUI frameworks

blog.royalsloth.eu

39 pointss9w27 comments

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

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.

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 It looks pretty Flutter-like.

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.

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.

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

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

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

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.

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.

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

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.

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.

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

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

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.

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

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

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

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.

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.

A website

Oh, come on. html/css+js is capable, but the programming interface sucks. Surely, you can at least imagine something better.

So you'd rather use a website to do heavy photo manipulation (Photoshop), edit a feature-length movie (Premier Pro), or compose GPU-heavy 3D effects (Nuke)?

> 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

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.

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

Reply on news.ycombinator.com