[thesuperbigfrog]

This is a great step forward, but it seems like a great deal of overhead and complexity to have a cross-platform GUI.

If I were creating a new cross-platform desktop application I would probably reach for Java instead. I know that's not the popular answer, but if a .NET Core cross-platform GUI requires either using Electron or simulating a client-server setup with Node then it's not there yet.

To illustrate, here is the "Hello World" cross-platform GUI application in Java:

https://docs.oracle.com/javase/tutorial/uiswing/examples/sta...

Setting up a connection between two processes and building async handlers is way too much if the application is running on one machine.

[vips7L]

Swing is probably the wrong choice if youre going java. I do electron everyday for work and we use stdin/stdout to farm json to a Java process as well. Given the chance I would probably use JavaFX over Electron or Swing. The FX app will be easier to style than swing and Gluon just announced native compilation support via Graal for new FX apps [0].

[0] https://gluonhq.com/gluon-substrate-and-graalvm-native-image...

[thesuperbigfrog]

I agree with you. JavaFX is better than Swing for most use cases.

I gave the Swing "Hello World" example because it shows a minimal, simple example of how little code is needed to create cross-platform GUI in Java.

JavaFX is also technically an external library now since Oracle spun out JavaFX to OpenJFX and Gluon has taken over development and maintenance, although many but not all OpenJDK distributions include it.

[vips7L]

Makes sense. The tornadofx hello world is pretty minimal too:

    class HelloWorld : View() {
      override val root = HBox(Label("Hello world!"))
    }

    class HelloWorldApp : App() {
      override val primaryView = HelloWorld::class
    }

I've bee conflicted in my research on choosing Tornado or default JavaFX

[thomascgalvin]

I'm waiting for Tornado to support Java 11+ before I jump on the bandwagon. It's getting closer[1], but it's still not production ready, from what I can tell.

[1]: https://github.com/edvin/tornadofx/issues/899

[vips7L]

Well I guess that makes it easier. I'd rather write Java than Kotlin anyway.

[thomascgalvin]

Really? That's the first time I've ever heard someone say that. What is it about Kotlin you don't like?

[tannhaeuser]

Last I checked (late last year) JavaFX hadn't HiDPI support.

[vips7L]

According to the release notes for version 8 HiDPI is supported.

[tannhaeuser]

Is that for Gluon? Sorry for not looking it up myself, but it's probably worth pointing out that at least Swing has (kindof) Oracle and a major Java desktop app behind, whereas JFX hasn't seen any love at all. I played around with JFX a couple years ago but there were serious problems with its WebKit integration. Coming to think about it, I'm wondering if there are any plans to integrate JFX and WebKit on GraalVM as a serious Electron contender.

[efdee]

Good luck getting that Swing app to look nice, though. Which is a breeze with HTML/CSS.

[thesuperbigfrog]

Customizing the appearance is one place where Swing's age shows. It is possible to create a custom "Look and Feel", but it is not as easy as HTML / CSS:

https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/

JavaFX does allow CSS to be used to style it:

https://docs.oracle.com/javase/8/javafx/user-interface-tutor...

[Crinus]

I remember >10 years ago there used to be some "plaf" libraries that provided very easy themeing abilities for Swing that even came with a WYSIWYG tool to create themes. It is a shame something like that never became part of Swing itself and instead you have to create tons of classes just for a theme.

[pjmlp]

Or actually buy them.

http://www.jgoodies.com/ is still in business, to give a possible example.

[Crinus]

This doesn't fix the issue of Swing theming being hard. The fix would be to make it much easier, preferably with a visual editor.

[pjmlp]

You mean like Netbeans Matisse, or more like actually having a designer on the team?

[pjmlp]

Not only it is a breeze, after reading books like "Filthy Rich Clients", I have full control over hardware acceleration instead of playing CSS tricks with Z ordering in the vain hope that the browser will do the right thing.

Lack of design skills doesn't improve just because one changes UI stack.

[tannhaeuser]

Swing can look fantastic if you put in the effort as IntelliJ (based on Swing) shows. I'm not necessarily an IDE guy, but good luck with getting that kind of functionality with JS on Electron even remotely.

[efdee]

I wouldn't say IntelliJ's stuff looks -good-. It's a lot more workable than most Swing apps but it's still a long way from looking "good".

That said I haven't touched their IDEs in 2 years so maybe something changed.

[jen20]

I'd say IntelliJ looks like it belongs on the platform it is run on - which I'll take any day over some over-designed cross-platform 'styling'.

[Crinus]

The problem with Swing theming is that you need to create a ton of classes "just" for theming your application. I did that years ago myself, but really Swing should have something like those libraries released years (>10) ago that had a bunch of premade themes as well as WYSIWYG editors for them.

There used to be many libraries (most of them were awful, half of them tried to mimic circa 2002 Mac OS X Aqua) so i do not remember any names, though i remember trying one with a visual editor that i gave to a designer at the place i worked at. We didn't ended up using it though because of the price.

[bluejekyll]

Would that Java application be capable of running in the browser? JavaFX, maybe?

[thesuperbigfrog]

That "Hello World" example uses Java's Swing GUI framework which is older and does not port to the web as easily as JavaFX.

Here is the JavaFX-based "Hello World":

https://docs.oracle.com/javafx/2/get_started/hello_world.htm...

There are also numerous Java to Web frameworks and solutions like TeaVM (https://blogs.oracle.com/javamagazine/java-in-the-browser-wi...), JSF (https://javaee.github.io/javaserverfaces-spec/), and many others, but at that point you are no longer talking about just a cross-platform GUI--you are talking about a web application.

[bluejekyll]

Isn’t that generally the main benefit of using electron based apps? The ability to target both desktop and web?

We can bemoan the inefficiency of this, and how wasteful it is, but at the end of the day, it’s a very portable way of delivering applications.

I think VSCode is a huge success because of this model.

[thesuperbigfrog]

>> Isn’t that generally the main benefit of using electron based apps? The ability to target both desktop and web?

Yes, but then what would be the point of ElectronCGI?

If the goal is to target desktop and web then Electron is a great choice. There are many popular Electron-based applications that show this, e.g. Slack, VSCode, etc.

ElectronCGI is supposed to provide a cross-platform GUI for use cases where the full Electron stack is not wanted or perhaps not available.

I applaud the effort, but it strikes me as a strange choice since it brings the client-server and async complexities from web programming into a desktop environment. It seems like a very niche use case. Perhaps if you have a large .NET codebase that needs to be available as a cross-platform desktop application, but for some reason you can't use Electron / Blazor ?