Ok, so this starts off as “Graphics for the JVM” which sounded promising, but then the first line starts talking about desktop apps and warning bells start going off. If you read the post, it’s totally fine…if you are trying to do fast drawing or something. But no, we’re making desktop apps, with circles and triangles and squares. This just isn’t how it works, and the reason is the same as it always has been: a drawing toolkit is not a GUI toolkit.
If you want people to make good apps, you need to give them buttons and checkboxes and text fields. If you don’t, we’ll, they’re going to do it wrong. Time and time again people have tried doing this and the best we’ve gotten out of it are game UIs and Flutter, which are a solid “mediocre” in the UI department. The former probably gets a pass because it’s allowed to be quirky, but the latter is literally run by a megacorp and it’s still struggling to get basic things right.
Heck, even Swing and HTML are better than this; at least they give you components that someone actually spent time on implementing and making half-decent. Maybe they suck, but they suck together in a consistent way that is at least partially battle-tested, a must for any GUI toolkit. They’ve gotten to the point where they’re no longer just a middle finger to people with accessibility needs.
Look, I don’t want to rain in this author’s work. If you’re going to treat it as an accelerated Graphics2D, go right ahead, this seems like it would be an excellent solution for you. JVM bindings to Skia seem awesome. Just don’t, like, draw something that looks like a GUI in it.
(I could go longer about the characterization of mobile apps as constantly being purged from RAM and losing your work and IntelliJ being a good Java UI, but that would probably make this divisive comment longer than it already is.)
I think you misinterpreted what the author aims to do. He states in the beginning that the main reason for why we don't have a good UI toolkit on the JVM is because every existing solution is bringing its own drawing library and with it their very own limitations. He advocates for a drawing library that will be supported community-wide, something like Spring is.
React Hooks, SwiftUI and Flutter are modern choices that popularized the declarative approach and the author expresses its frustration that until now there was no interest in developing one for the JVM, which has all the pluses that it needs to create an ecosystem around one. Java, Kotlin, Scala and Clojure will all benefit from it. I think he is right, there is no modern graphics API on the JVM right now to do an UI toolkit or 2D/3D visualisations.
"The road to high-quality UI on JVM is a long one. We’ll need:
a graphics library,
a window/OS integration library,
a UI toolkit.
Today I am happy to announce the first part of this epic quest: the graphics library"
Maybe you misread a bit? I do not see him suggesting, to use his first step for the UI. The idea is to build the UI kit on top of it.
I get that, it’s just that this is being presented as something that will kill Swing and Electron, which obviously makes it so that many will take away “I should use this to draw my buttons” from it. I’m advocating caution before throwing away Swing right now.
Well, his intention is to create something that will eventually kill Swing (and Electron), so he probably got carried away wih his words a bit, but I do not see him missrepresenting.
This is a blog post, not a product launch. It's intended to be a foundation on which a "real" GUI library can be written. The author mentions that it is one of several steps that should allow the Java community to coalesce around a better toolkit in the long term.
I think it's confusingly worded b/c they compare to Swing and JavaFX in the first lines - so it sounds like this is aiming to replaces those. But in-effect this is just a first step towards that larger goal. Why the graphics library needs to be rewritten from scratch and they couldn't implement a better UI toolkit on top of what already exists is left unanswered - and that's confusing. All it says is "Java UI progress was blocked by the poor-performing Graphics2D"
This post is only about the Skia JVM bindings and that is indeed only the graphics layer. What you are looking for is Jetbrains Compose which is built on top of these bindings and provides the GUI toolkit.
The particular issue I have is that when you look at a library like this, and especially how it’s being sold, we’re just going to have people go “Wait, I can just draw my own UI toolkit! This is easy!” and they’ll end up with something worse than Swing because they don’t realize the work that went into Swing even though I’ll be the first to admit it’s not the best. So I guess what I hope this becomes is that a group of people who actually understand desktop UI come together and take this to make a good toolkit, and I’m trying to caution people who want to just dive in without fully understanding what this would offer them. An analogy might be a blog post announcing LLVM IR, and I advising caution against just going and writing your homebrew language against it and then shipping your software on that. This is just a part of a good UI toolkit, and I think the blog post is looking too far into the future.
Sorry if I got the wrong impression. It’s an easy impression to make when you keep complaining in multiple comments that the article is omitting key things that are actually discussed in the article.
Perhaps it’s just the way you were communicating your opinion that is misleading. It’s not just me, I can see at least three or four people here who are trying to point out things in the article that you seem to have missed.
I will concede that my original comment was unclear; I am not particularly annoyed I had to clarify it a few times. I was just (somewhat unreasonably) annoyed that poeple thought I hadn't read the article.
> Ok, so claiming I didn’t read the article is actually against the guidelines, and you’ve done so twice so I’m not particularly in the mood to really entertain it anymore.
First off, you are responding to two different posters. Second, neither vbsteven nor jb1991 said you didn't read the article, they pointed out things that were addressed in the article. The phrasing they used is explicitly called out as acceptable in the guidelines:
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
No, I am responding only to 'jb1991; here is the other comment you missed: https://news.ycombinator.com/item?id=25122691. I was annoyed because the sum total of those seemed to be a claim that I did not read it, not just a straight quote (which I had a few of already, mind you).
No, I read the post, the author mentions that this isn’t a GUI toolkit. But the reason I made the comment is that like 90% of the post is “we need desktop apps and Swing sucks and let’s not use Electron” so I think regardless of what it says in the middle it really seems like it’s selling “use this to make your desktop app” rather than “this is a general-purpose graphics library”.
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.
I assure you that I’ve read the whole thing, and since I’ve already answered this question a couple times in this thread, I’ll direct you to my responses there.
The author is exhibiting heavy denialism. The first indicator was gesturing towards IntelliJ IDEA as an example of a good desktop app. And whaddaya know, it turns out the author is affiliated. This isn't to say there's any intentional deception here—it's somewhere between self-deception and simply being unaware of one's own blindspots.
Without going through the effort of installing and running it, it's easy to see that IDEA looks just as good as it did 5 years ago—which is to say not great. And without any evidence saying otherwise, it's reasonable to assume that it hasn't gotten any more lightweight or nimble since then, either.
People writing JVM apps who tout their quality never seem to understand that their firsthand experience does not translate to other machine/system configurations that other people are running. It very well may be the case that those apps look and feel worse than an Electron app. (And one doesn't have to be a fan of Electron apps to admit this.)
It has actually. It starts a lot faster, and has a "lite" mode where it's more like a text editor.
As for how it looks, well, it's an IDE. It looks fine to me. There's a dark mode if you want it, the look is modern yet dense: sparsity being a common issue with web apps. Plenty of people use and like it.
The point about information density cannot be stressed enough for a "pro" tool.
Its keyboard friendliness is also highly underrated due to being a GUI -- I found it's rivaled only by emacs/vim in that I can go an entire work day without clicking around with a mouse.
It has nothing to do with dark mode. Dark mode screenshots are the first thing you'll see when you go looking for how IDEA looks today. It looks like a dark version of the UI from 5 years ago, unsurprisingly. Which means it still looks about as out of place as any Electron app. Although one would hope they've dealt with the bad antialiasing by now. Hard to say without downloading and running it, but the continued lack of polish and past propensity to pass the buck makes one question, "why bother?"
> As for how it looks, well, it's an IDE.
Not sure what this is supposed to mean. There are good looking IDEs. There's not something inherent to them that makes one look the way IDEA looks. It's the aforementioned blindspots and the "I don't see anything wrong with it" attitude that causes that.
My point is, I don't see the problems. Anti-aliasing works fine. The text looks good to me, always did. Looking out of place ... well, on macOS at least you can pick a mac-like theme. I don't because I prefer the IntelliJ theme but there's not much difference to it. All Mac apps are Windows 98 style battleship grey these days, the era when native toolkits had radically different looks to portable toolkits is over for a long time now.
If you want people to make good apps, you need to give them buttons and checkboxes and text fields. If you don’t, we’ll, they’re going to do it wrong. Time and time again people have tried doing this and the best we’ve gotten out of it are game UIs and Flutter, which are a solid “mediocre” in the UI department. The former probably gets a pass because it’s allowed to be quirky, but the latter is literally run by a megacorp and it’s still struggling to get basic things right.
Heck, even Swing and HTML are better than this; at least they give you components that someone actually spent time on implementing and making half-decent. Maybe they suck, but they suck together in a consistent way that is at least partially battle-tested, a must for any GUI toolkit. They’ve gotten to the point where they’re no longer just a middle finger to people with accessibility needs.
Look, I don’t want to rain in this author’s work. If you’re going to treat it as an accelerated Graphics2D, go right ahead, this seems like it would be an excellent solution for you. JVM bindings to Skia seem awesome. Just don’t, like, draw something that looks like a GUI in it.
(I could go longer about the characterization of mobile apps as constantly being purged from RAM and losing your work and IntelliJ being a good Java UI, but that would probably make this divisive comment longer than it already is.)