Also NetBeans.
I'm not convinced that JavaFX is too slow for use in real-world GUIs. The article doesn't really back up this claim. It also ignores the SWT toolkit, used by Eclipse.
Unfortunately I find the last part a bit confusing: is this the lower level of the stack that beneath Compose Desktop? How is skiko related, or is it unrelated? Apparently Compose Desktop is built on Skijo (the github readme is much less confusing). Apparently the skiko build is also consuming skija as a dependency (in some very interesting ways, apparently planet kotlin still does enough java to lombok it), but the presentation on the blog would benefit a lot from a healthy dose of clear "that uses this" bragging.
All in all as a slowly greying java guy, it's amazing to see this entirely unexpected breath of fresh air for the JVM. In this age of new desktop apps having been given up completely to electron and the like, desktop JVM could see a surprising renaissance as a lesser evil.
Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI.
> desktop JVM could see a surprising renaissance as a lesser evil
I'm not convinced that a whole new toolkit is the solution, with all the challenges that brings (lots of widgets to create, internationalisation, accessibility, multiple platforms to test on, etc). I figure the better move would be to work on improving JavaFX. As far as I can tell it's a pretty solid GUI toolkit, albeit one with little adoption.
edit Also, I suspect one of the things holding back Java desktop GUIs might be that they're often clumsy to distribute. Expecting the user to install the JVM isn't good enough, the application should bundle a JVM, or use ahead-of-time compilation. The user should never be made aware of what language you built the program in. As I understand it, OpenJDK has been making solid progress on the latter option. (And Excelsior JET no longer exists.)
A right, I forgot that, thanks. What's the SWT approach to use cases where you basically want a pixel canvas? Falling back to AWT on a surface allocated from the native API or its own facade for native APIs?
In any case this property of SWT kind of explains the omission, SWT happens on a level that is two layers away from skija in the stack Jetbrains are building for Compose Desktop.
I don't think SWT makes any use of AWT, I believe it does the latter.
> SWT happens on a level that is two layers away from skija in the stack Jetbrains are building for Compose Desktop
The article is making the case for a whole new GUI toolkit for Java, without making a persuasive case against JavaFX (I'm not convinced that its performance is a problem), and without mentioning SWT, the foremost 'unofficial' desktop GUI toolkit for Java. Skija may have its merits as a platform for 2D graphics, but that's not the point.
Incidentally, the article's title is misleading. It's about GUI toolkits, not graphics libraries.
Maybe it's a bit dishonest to present Skija as if it was made for any other reason than to enable Compose Desktop, but it's very laudable to have the ambition to be more than an enabling component of that.
Many similar approaches have been done, but none became a conveniently dominant go-to solution. Perhaps AOT compilation will finally bring a JRE bootstrapper component that is sufficiently "java" to find a wide footing in the java dev community and sufficiently friendly to end-users to end all "but maybe that other tool is even better" that kept all existing approaches niche.
I just download Netbeans, this is 10+ years since I touch a Swing / Java apps. And nothing has changed, it still looks Java. It is still heavy, although start up speed are now better. But generally speaking an Electron Apps ( VS Code ) looks and works better than that.
Eclipse is still better look wise, as it was 10+ years ago. That was basically the reason why I choose SWT back then. But it is still not perfect.
So I decide to check out another consumer Desktop App from similar era, Vuze, or used to be called Azureus. And it is the same, Desktop Java Apps. And yes that was the reason why no many were using Consumer Desktop Java Apps. They dont look good, heavy on resources, need JDK etc....
As if nothing has changed in the past 15 years. I remember I was trying to use GCJ and SWT for Desktop Apps then, it was just too hard. I gave up. And it seems no one cares about decent, java desktop apps.
I think the Nimbus look is ok. [0]
> It is still heavy, although start up speed are now better.
It's certainly heavy. iirc NetBeans spins up over 20 threads even if you're not doing anything. As for startup times, is this on the same hardware? I imagine SSDs must help with NetBeans startup.
> trying to use GCJ and SWT for Desktop Apps then, it was just too hard.
There was a proprietary payware alternative to GCJ called Excelsior JET but it was discontinued 2 years ago. [1]
[0] http://wiki.netbeans.org/wiki/images/b/b2/Vista_Nimbus_Scree...
I would like to have an opinion on this myself but I've yet to find a JavaFX application in the wild.
There are many aspects to UI performance. Unlike IntelliJ, our app has only tens of widgets displayed at once - I can't compare in this regard.
However, we have very big models, namely tables with >100000 of rows. Scrolling is smooth and initialization as well. From my experience, JavaFX allows you to write elegant code which still caches a lot of components. This is a strong performance benefit.
My issue with JavaFX is a very well thought-out philosophy, translated into an API which is far from perfect. Once you go beyond "hello world" examples, you e.g. have to start type-casting. I'd love to see JavaFX v3 where these things would be sorted.
By this point, it should be table-stakes that any GUI framework must always be tapped into identical font rendering to native apps on the host platform.
https://github.com/geokon-gh/corascope/
I even managed to make a little SVG backend for it
That said - this seems to be more of a " graphics library " while JavaFX is more of a " user interface library ". I'm sure there is a ton of overlap - but I wouldn't be making funky creative coding displays directly in JavaFX
My minor annoyance is that it's nearly impossible to make something that runs on Android out of that - which seems like a giant shame given it's all JVM