I know Compose exists, and it’s exactly the concern I have: look at the example apps, and compare them with true native desktop apps. Can you really call the result a good desktop UI? Is it not just a mobile UI that was blown up? Actually, it’s difficult to even call it a good mobile UI, because at the moment it certainly falls on the side of “bunch of shapes put together” rather than “UI toolkit”. Of course, while UI is just a bunch of shapes on the screen, it needs to be cohesive, and familiar, and accessible; not to mention the many, many behaviors under-the-hood that don’t show up in a screenshot.
> I know Compose exists, and it’s exactly the concern I have: look at the example apps, and compare them with true native desktop apps. Can you really call the result a good desktop UI? Is it not just a mobile UI that was blown up?
Because the project is in alpha? And it says so on the page?
To quote from the article on skia:
--- start quote ---
We are so used to things we can hack together in a week, nobody is thinking in terms of years. And good UI requires years of work. It’s a big commitment.
The road to high-quality UI on JVM is a long one. We’ll need:
The author of the blog post works for JetBrains (I think). JetBrains are interested in moving away from Swing for their product line. Their intended replacement is a port of JetPack Compose to the desktop, perhaps because it's a Kotlin-centric framework and Kotlin is their baby, perhaps because Google is funding Compose and they hope that it'll have more money invested in it than Swing/JavaFX did.
Compose renders with the Skia graphics library. Hence, Skija and Skiko, bindings to Java and Kotlin respectively. And hence their Compose for Desktop effort.
The grandparent comment is questioning whether a mobile toolkit ported to desktop is really going to become competitive with Swing anytime soon, given that although Swing is admittedly by now a very old API, it's been continuously developed for 20+ years and is thus by now one of the most battle tested and matured frameworks in the world.
Now you might ask, but aren't Skia bindings useful in and of themselves? Well sure, maybe, but bear in mind Java has had a Skia equivalent for a very long time via Java2D as used in Swing, and JavaFX also has a Skia-type subsystem where you can issue drawing commands and they get hardware accelerated. So to understand the value of this new library you very much need to be able to do an in depth comparison of Skia vs Java2D vs the JavaFX Graphics subsystem. Very, very few people have the expertise to do this and the blog post doesn't really try.
I've actually looked at this topic in the past few months for various obscure reasons. I'll say that:
• Skia is the core of Chrome so it's actively maintained, which is good. On the other hand so is Java 2D.
• Skia seems to have some support for playing animations exported by a visual animation builder called Lottie, which is nice. Java 2D doesn't have that.
• You can partly embed Skia in a web page via WebAssembly, which I guess is neat. You can embed Java2D in a web page via stuff like TeaVM too though.
• There are no benchmarks comparing these libraries, as least not as far as I know.
• They are both hardware accelerated via OpenGL / Direct3D. Skia also has experimental support for Vulkan.
• Skia is a C++ lib that therefore requires manual bindings to other languages. Java2D/JFX are JVM APIs that can be automatically bound to a wide variety of languages, e.g. JavaScript, Python, Ruby, etc.
• Skia's documentation is rubbish. Check out this excuse for a website: https://skia.org/ - a 2D graphics lib is a complex thing. Where are the docs? E.g. click on the main API objects and you get a handful of semi-random examples with one line of explanation for each.
Basically, Skia is a component of Chrome that happens to have its own website. There is some vague attempt to make it into a real, production quality API but when internal docs for Skia developers drastically outnumber API docs for users, you know what you're dealing with. Java2D and JavaFX are designed to be APIs consumed by lots of developers, in a large variety of languages.
Sounds like in principle, Skija is an attempt to take the benefits of Skia and bring the shortcomings (for this use case) up to par. What's taken for granted is 1. Skia is better/more/performant/nicer than javaland status quo, and 2. Jetbrains has the resources/experience to "hand-craft" a nice Java API over it. And then on to all the other steps.
> So to understand the value of this new library you very much need to be able to do an in depth comparison of Skia vs Java2D vs the JavaFX Graphics subsystem. Very, very few people have the expertise to do this and the blog post doesn't really try.
This is the main point, which I can only assume JB have answered internally. They are probably the biggest Java GUI shop in terms of users and revenue (at least that I know of), so I'm not too too skeptical when one of their developers with some clout says "AWT, Swing, and JavaFX came with a lot of quality and performance drawbacks"
Eh, maybe. Familiarity breeds contempt. I think they feel like they're sort of out on their own with Swing and the cool kids are moving on to new things. They like the DSL aspect of Compose. Could the advantages of Compose be brought to Swing - probably. My guess is yes. But if Google are planning to spend the next decade heavily investing in a Kotlin-first toolkit and millions of Android devs will learn it, you can see how they arrived at the decision to go the whole way.
AWT actually uses native widgets, so if your needs are simple it's one of the fastest ways to go as the code is all loaded in memory already and written in C/C++, it's a part of the OS after all. Modern Swing isn't slow. IntelliJ's performance isn't limited by Swing I think, it's much more limited by RAM in general.
JavaFX never reached the maturity of Swing in terms of raw stability, but it's got a drastically better API and TornadoFX shows you can layer a Kotlin DSL on top very easily. Frankly I wish they were investing in JavaFX instead because it's actually a desktop toolkit, and is already "there", whereas Compose is going to be beta-ware for a long time. JavaFX has been stabilising over time because for the last 7 years or so it's not been adding many features, the work has all been bug fixing and performance improvements. It's a mature toolkit that just didn't quite get critical mass.
https://www.jetbrains.com/lp/compose/ shows a code editor prototype.