Hacker News Reader

Comment by pdntspa | Hacker News Reader

I just wish its cross-platform UIs weren't such a mess. Particularly with its MVCish implementation, it was like it couldn't decide what it wanted to be.

I really really wish there was a good, straightforward desktop GUI for .Net that simply worked crossplatform and wasn't a complete pain in the ass to program.

View on HN

In their defence, does any other language have one, these days? The landscape hardly looks good, which is how electron et al. got so popular to begin with.

Java and Python have a few. I still don't get how electron got so popular. It's always been pretty straightforward to ship an app with a self-contained Java runtime, much the same as electron ships with v8. Java GUIs have always been worse than c++ ones, but still.. much better than electron I'd say

And now try to get either to work mobile, or in a browser, or at least try to share frontend code between them. That's where electron shines, and all the "classic" frameworks really don't. QtQuick and JavaFX kiiiind of work for at least some platforms, but it's fairly rough all considered, even compared to the inelegant brute force solution of electron.

I'd put my money on the competing "electron, but smarter" solutions that keep bubbling up, rather than any language-centric framework.

I wish that CodenameOne could have been the norm instead of Electron. Unfortunatrly, its desktop port never matched its mobile one in terms of functionality (still uses JavaFX for web views). I still prefer it over Electron where web views are not required i.e. nowhere

I hate that we are completely enamored with browsers. Desktop apps and browser webapps are different platforms, with different methodologies and motifs.

I hate hate hate it when a desktop app looks and acts like a web app.

pySide6 has been a dream for me, it 'just works' and QT is quite robust.

I am currently fucking with Java via GraalVM, and packaging my app for distribution has been absolute hell:

jlink throws errors.

jpackage somehow gets stuck in an infinite loop that generates a directory tree of seemingly infinite depth (so deep that even Explorer can't delete it)

GraalVM native-image can't complete and throws all sorts of weird error messages

Trying to modularize the app has been hell too, it seems like every one of your dependencies needs to be modularized as well?

And like all I am using is Swing, FlatLaf, and MigLayout :(

How the hell are people getting apps running in a standalone environment?

I really like Java the language, but getting a desktop app running on it in 2023 is a nightmare.

I don't know anything about the QT on python as a runtime. Is it supposed to be just as fast since it's bindings to C++, or is it noticeably slower?

I haven't done anything terribly performance-sensitive with it, but what I have written has performed extremely well. My app starts up to its main window instantly (which SHOULD be table stakes...)

> I really like Java the language, but getting a desktop app running on it in 2023 is a nightmare.

This is honestly because you are taking the hard path and trying to do AOT compilation. Just use Swing with HotSpot. Native Image isn't meant for GUI applications and Swing internally uses a TON of reflection.

Using jlink and jpackage with HotSpot has been trivial in my experience.

I'll look into that, thanks

Also check out Hydraulic if you need more than just packaging, it includes things like autoupdate and custom launchers: https://conveyor.hydraulic.dev/12.0/configs/jvm/#overview

Try https://conveyor.hydraulic.dev/, we replace or drive the whole deployment stack and have plenty of JVM using customers. It's a lot easier, try it out and see if it works for you. I should say though, that the support for native image is experimental.

When I am ready to mark the github repo as public I was going to consider Conveyor, as paying money for it is a no-go right now (unemployed and broke rn)

Not sure if it suits your use case, but the best I have experienced is jDeploy

Interesting... I like how it piggybacks off npm

>jpackage somehow gets stuck in an infinite loop that generates a directory tree of seemingly infinite depth (so deep that even Explorer can't delete it)

This happens when your jar is in the same folder as the working directory: https://stackoverflow.com/a/64743880

>I really like Java the language, but getting a desktop app running on it in 2023 is a nightmare.

I think it's very easy. Do you use a build tool?

I am using Maven

Getting the jar file is easy. But its deploying it that has been difficult

I think you had a massive number of exclusively JS developers out there who couldn't build a UI outside of a website but wanted to. Then Electron came along and gave them that power. That's how it got so popular, imo.

Lazarus for FreePascal, write your code hit compile and get a nice EXE that starts up on Mac/Windows/Linux

I think you can always train devs, but lots of companies will avoid Lazarus/Delphi like the plague

The Windows only desktop UI is a huge mess too. It reminds me of Babbage and his Difference Engine that could never be finished because part way through, he'd come up with "even better" ideas and start a new one.

I would say Blazor is really very very good now. One of the most awesome things about it is that your skill with it transfers almost directly between a desktop app, web API, or web site. All the code is almost the same.

Blazor is just history repeating itself. This is Web Forms with a shiny coat of paint and the "magic" this time is WebAssembly and a different proprietary web interface that is undebuggable.

I've heard this "Microsoft has finally created a completely cross platform UI framework" like twenty times...

It is nothing like Web Forms (I've built dozens of Web Forms and Blazor apps so I know), and WASM is just one delivery vehicle for it. You can also render it server side or locally in-process in a full .net runtime (no WASM needed). The debuggability for the WASM runtime has improved alot as well since .net 7.

Not first-party, but AvaloniaUI is doing pretty well in the cross platform department.

AvaloniaUI is miles ahead of any other cross platform library that I've ever used. It actually looks good!

I forgot to mention that I was referring to Avalonia, but when I tried to write something relatively simple beyond the music-player demo app, I got lost in the weeds extremely quickly. Avalonia needs a lot of work on its documentation, there are huge gaps, the quality is really inconsistent, and its abstractions fall apart really quickly

Not a conventional option, but I've built a few (non-game) GUI applications using Godot game engine + C#. Works great, intuitive once you get the hang of the UI system, fully cross platform (for 3.x anyway - Godot 4 still has a few unsupported platforms - android, web, ios - android support is ready for next release, ios has a PR that I haven't checked up on but I believe it was also nearly ready. Just web that is lagging last I checked.)

They should have fixed up Wine to run Winforms flawlessly, and it would have solved the cross-platform desktop problem.

<3 WinForms

UI frameworks are a heavy lift, more-so to be cross-platform. Let's say someone tries, but it's not to your liking? I mean, there can't be 12 different frameworks, that's not sustainable.

I am really flexible in terms of a toolkit's ergonomics. But I am running into situations where things just straight up don't work (Java/graalVM), or that I need to implement some really basic interaction and there is no guidance in the documentation and the abstractions don't make any sense. (Avalonia)

And that's assuming it even compiles or packages.

So far the only winner has been QT (via pyside6 for me)

I get it. And I completely agree on Avalonia. Personally, I'm not a big fan of that style programming where xml-ish glues stuff together. Makes hunting down errors a nightmare.

What doesn’t work with java/graalvm?

I outlined my issues in this comment: https://news.ycombinator.com/item?id=38266151

Someone suggested switching the JVM to hotspot and using jlink/jpackage, I am going to give that a shot

Depending on what you want, there might not be too much point in going native. Also, it is unfortunately true that GUI stuff is not yet well-handled by Graal AOT.

I was drawn to the prospect of having a single EXE and having it run as native code

On graalvm 20 I even got it to compile, but there were issues drawing/loading swing components

Avalonia + FuncUI (for a MVU design) seems to have a lot of fans.

There is not and wont be. MS will commoditize apps to bake as many features as possible as fast enough as possible using some bastardized Electron crap.

Reply on news.ycombinator.com