Hacker News new | past | comments | ask | show | jobs | submit login
Graphics for JVM (tonsky.me)
564 points by agluszak 7 days ago | hide | past | favorite | 364 comments





We build all our desktop products using Swing, and it works pretty well. Looks pretty native (if you want it to), is thoroughly battle-tested, reasonably performant, and has a bazillion open-source extras floating around (of varying quality).

If you need 3d, we drop into OpenGL and use that (e.g. when integrating WorldWind).

Sometimes I feel bad about how easy it is to write desktop UIs in Java - the API is stable, nobody keeps changing it under me, I don't have to wonder what Microsoft is pushing this year, it is (mostly) easy to debug, has open source forms designers (Netbeans), etc, etc.


I have a long history with Swing and as painful as it is to use sometimes (e.g. "There are Swing developers with low pain tolerances?") it's astonishing how productive Swing feels compared to React even so many years later. Maybe I'm just warped but GridBagLayout, while containing a certain base level of frustration, is O(1) for frustration. Whereas CSS are absolutely O(n) or worse. One of the best feelings in the world is replacing a complicated nesting of buggy BorderLayouts et al with one nice (slightly verbose) GridBagLayout that actually works.

In my imaginary company that I own where we all run linux laptops that are managed by puppet or something, I think we might make a strong case for building many internal tools in Swing.

The biggest hurdle I see nowadays to using Swing is all about distribution: both of the jvm and the program. Imo that's really where the web won - certainly not because of its dev productivity. So it's definitely a no-go for your actual software product.... but for internal tools where you have a lot more leverage over the environment, I think it looks extremely attractive.

Regarding JavaFX... Honestly, I really like it. I have a personal project that was originally in Swing and I ported it to JavaFX because HiDPI is in a lot better shape there (though I think Swing has since figured it out?). And it's a lot better in many ways. I love-love-love using SceneBuilder for designing the view layer and the Observable pattern, I think, yields a lot of nice QOL/verbosity-reducing things.

That said, I think it did have a slightly higher O() for frustration than Swing's O(1). And I think the community, as a whole, just understands it less (less prior art etc).

So if someone said "build a usable high-quality GUI asap or you die" to me, I'd go to Swing immediately.


Ahh ! Gridbaglayout! I hated it so much ! Then I had to work with CSS and JS and I began to realize the genius of the Gridbaglayout!

I'd strongly recommend looking at miglayout [0] if you have to do another UI in Swing (haven't tried it with JFX). It's pretty much the best layout library I've seen, bar none, for developing UIs in Swing. You can think of it of GridBagLayout on steroids, and it even handles things like reordering buttons on a per platform basis (eg. Ok and Cancel on a dialog are in Ok/Cancel order on Windows, Cancel/Ok on Mac).

[0] http://miglayout.com


The link seems to be broken in some way. The page I'm getting is unrelated to miglayout.

My buddy worked on a niche volumetric (voxel) renderer for ages. I helped with some of the OpenGL bindings and plumbing.

Java Web Start (JNLP) worked great. It just worked. His customers loved him.

I've always wondered why something like desktop JNLP didn't happen.


I owned development of a JNLP app around a decade ago.

JNLP did a good job of solving the app distribution/update problem, but required that you already had the JRE installed. Not too much different from assuming a browser is installed, but I found it much less likely that a user would take the initiative to install a JRE than a browser. They just don't understand what they are doing or why in the case of the language runtime.

That said, it did work very well, in my experience.


I'll echo this. I owned a jnlp app, and most of the support we had was around walking people through installing a sufficiently correct jre. Not always easy to do that

When I was developing a Swing app, I ended up just distributing an NSIS installer that would automatically download and run the JRE installer if Java was old or missing, for that reason.

I would have bet money the JNLP installer did this. But I'm probably remembering wrong and will defer to the collective wisdom of the hive.

I am about 90% sure there was some sort of 3rd party open-source wrapper that would download a jre. But I cannot remember what it might have been called

Why apps don't just install a copy of the JRE (I believe it is redistributable).

When you're distributing a real installer with a swing app, including a copy of the JRE is definitely the thing to do.

A jnlp app is a file format that defines how to launch a java executable over the internet. It defines the location where the executable is, and what version of java is required. Opening the jnlp to download and launching the app requires an installed JRE, or there is nothing to interpret the jnlp and go get the application.

There is, iirc, a utility that will wrap a jnlp file and go get a jre. I forget what it's called, but it makes jnlp apps more like an auto-updating standard app.

The benefit of the jnlp approach is if you can guarantee your users have java installed, then they don't need to install your app. Just click a link, then a java app self-downloads, installs and sets up a shortcut on the desktop. And it updates whenever they open it and a new version is detected.


I've always wondered why something like desktop JNLP didn't happen.

Wasn’t that Marimba/Castanet?

https://www.wired.com/1996/11/es-marimba/


It failed because,...

A.) ...they never figured out a good/unobtrusive update process for the JVM itself.

B.)...Sun faltered when they picked up steam. (Remember when IBM threw 1 billion USD at writing Eclipse in Java?)


And Eclipse was hands down the best tool for Java development... Until it was left to rot, and JetBrains came along.

GridBagLayout... haven't heard that one in a while. After dealing with CSS madness for years perhaps I should give it a try again.

> I think swing has since figured [HiDPI] out

I hear Java GUI has supposedly gotten better, but all of the Java GUI apps I see look awful. For instance, try telling that to Ghidra and it's butt-ugly text that shows up super thin on my hidpi display. I like Ghidra, but for a graphical RE tool, Cutter is so much prettier with its QT interface. Of course, r2 is great and works from CLI.


JetBrains products are all Java GUI apps and people love them. Depends on the team building it more than the technology.

I say that some who likes Jetbrains and buys their products:

No one in his right mind loves the UI of Jetbrains Apps and the Linux experience has always been a shitshow unless you were using Gnome or KDE. Because Swing does not implement the XWindows protocol properly. So yeah, a great team can still make a functional app with terrible GUI technology -- but there is a world of a difference to something that's really polished, fast and enjoyable to use.


I think IntelliJ has the best UI of all IDEs I've seen, it sure as hell beats Visual Studio (the paid one), it beats Netbeans, Eclipse.. What else?

VsCode and atom are simpler, but they just don't provide UI, for many setting you have to go to config files, and some functionality is missing outright.

Can you think of an IDE with better UX?


Jetbrains products are my preferred choice for full-featured IDEs, but this is not exactly an industry renowned for producing snappy and pleasing interfaces. And since LSP has narrowed the gap, most of the time I don't require the features that would make up for the bad UX so the majority of my coding happens outside an IDE.

MacVim is my favorite when it comes to UX. It starts instantly and stays fast even on huge files. It's very customizable and works exactly how I want, including the layout of nested horizontal and vertical split panes.

I like being able to configure just about everything in just a single config file, but still getting an additional escape hatch for overriding OS default keybindings I want to use.


People love IntelliJ despite Swing because its other qualities make up for the slightly off-looking Swing font rendering, the glitching Swing layout redrawing and the glitching Swing window focus.

Also, the menu bar in IntelliJ was reimplemented from scratch to make it work properly. The Swing menu bar would have been unusable with its broken handling of submenus.


But they're ugly and impossible to use, for some of us. Just awful and horrible UI and flow... I simply do not get the love for IntelliJ anything.

Agreed, the only thing going for IntelliJ is that its easier to use than Eclipse, but the product is still too complex and ugly.

Really? I love eclipse. Though not as much as I used to.

I suppose preferences here are at least partially determined by how you think about software project management. Eclipse makes perfect sense to me, and has since the first day I used it. IntelliJ is obtuse and odd and ... wrong to me.


I agree that Eclipse is better than IntelliJ, but is not as easy to use. But after you get used, Eclipse is a better product.

Take a look at Bitwig

JavaFX also has much better emoji support IIRC

I am right there with you on gridbaglayout. And tools like WindowBuilder make it so fast to generate basically acceptable guis

"basically acceptable" is such a low bar.

For distribution check out Install4J

Swing is mostly fine. Ideologically, it's cousins with Qt.

I don't think Swing's MVC strategy worked out. It was worth trying. But maybe 40%-50% of the framework could be safely removed.

Some kind of DSL would be nice. JavaFX ain't it. In my own noodling, Swing's UI component hierarchy needed to be refactored to be fully composable. By the time I created enough shims to make Swing truly composable, I wish I'd started from scratch. (I haven't done Swing work in ages, so maybe this happened.)

An event loop is the biggest thing missing from Swing and other UI toolkits of that era. Meaning all modifications are handled by the framework, no client code (or non event loop threads) can modify the UI. My bestie George Smith's Juipeter (?) took the Win32 API approach, preserving the Swing API and all dispatch was handled under the hood. This is kinda how a browser's event loop is implemented. I much prefer an exposed event loop and Command objects. (It's easier to stepwise debug. Every desktop app I've ever created also had Undo/Redo; so you're gonna do Command objects one way or another.) And then make the framework pretty with some kind of DSL over the top.

Sadly, though inspired, I think Swing's LookAndFeel plumbing proved unnecessary. Sun believed everyone who said it mattered. Maybe it did for a while. But the world moved on. I still have no firm opinions on how I'd make an app reskinnable. (I should probably look to see what Qt's doing these days.)

Edit: I didn't mention AWT/Swing layout managers. Just peeked at Google/JetBrains Compose. Meh. I like that it uses Kotlin; less syntactic vinegar than Java. Alas, Compose repeats the mistake of not separating out the layout code. After doing way too much layout code -- some Australians did a hysterical GridBagLayout rage meme video, back in the day -- The Correct Answer[tm] is custom layout managers. Still include some stock managers in the JDK. And make the layout hooks API easier to implement and debug.


>Sadly, though inspired, I think Swing's LookAndFeel plumbing proved unnecessary. Sun believed everyone who said it mattered. It maybe it did for a while. But the world moved on. I still have no firm opinions on how I'd make an app reskinnable. (I should probably look to see what Qt's doing these days.)

Well, if they didn't bake LookAndFeel in from the start, all of the work would fall on the application developer to manage these things. Having had to look into doing this the way they chose is the best way, what most people have a problem with is the UI didn't look fully native on most platforms for a long time.


Honest question: can someone explain the focus a lot of the HN crowd seems to have on "native"-looking UI? I've used plenty of applications that don't look "native" and it doesn't bother me. Is there a reason to prefer it? I get that performance can be an advantage, but one can easily write a very performant application using something like Skia, or doing one's own GPU acceleration, without having any native look.

There are a few reasons to prefer a native look and feel.

One is that if the look and feel of an app is native to the platform then it can lean on a design language that users of the platform assume, which makes it easier for those users to understand how to use the UI. Affordances look and act the way they expect, which reduces the time and effort it takes them to learn a UI.

Another reason to prefer it is that a UI that doesn't look native stands out as different. Noticeable differences are information. If something in a UI gets your attention, it should be because it's telling you something meaningful. Gratuitous differences from the platform's UI standard are not telling you anything meaningful, so they're just noise.

A third reason is that native platforms provide their native looks and feels through standard frameworks that also provide substantial whole-system features beyond just making things look alike. For example, Mac users can rely on a common set of keystrokes to do the same things across almost all applications (and the exceptions are badly behaved). UIs built without the platform frameworks must either recapitulate all of these platform-wide conventions or just ignore them. Commonly, they just ignore them, which means that conventions that users take for granted stop working in some apps for no good reason.


Back in the day in Unix desktop land there were 4 or 5 different UI toolkits and they looked behaved in a massively different way. X looked like ass. QT looked less like ass but had totally overloaded UIs. The differences were even starker on lower-res displays.

Also back then browser apps were a novelty instead of how most people interact with computers most of the time, and thus anything that wasn't using a native toolkit stood out pretty bad. A few apps like MP3 players used it for their advantage, but I remember those as being mostly a confusing mess.

More importantly, font rendering has improved incredibly and most rendering looks the same across toolkits in the same desktop environment. Back then some toolkits supported antialiasing, some did not, some had godawful rendering that looked like crap, some couldn't render certain symbols correctly, some didn't have good hinting for LCDs, etc.

The reality is that very slowly most UI paradigms have converged into a few well-established patterns (no more multiple-window apps, no more focus-follows-mouse, no more deep right-clicked context menus, etc). So now the styling differences are more apparent but most UIs are functionally the same nowadays. The same could not be said 15 years.

We have come a long way; despite the different looks, the feel is much more uniform, and there's a better understanding of what makes for good UIs.

As I write this, I'm frankly quite thankful that we have reached this state of good-enoughness. Spending hours looking into GTK themes and different fonts was fun, but in a frustrating way in which no exact font-icon-theme combination was entirely satisfactory.


I don't think X ever had a toolkit of its own, but i would guess you are thinking of Motif, because your description is spot on:

http://www.ist.co.uk/motif/books/vol6A/ch-3.fm.html


Indeed. It was about the closest you'd get to a standard X toolkit.

It's a fantasy problem. Hold on before you downvote folks and count the number of 'native' applications that were written since year 2010.

Most consumer applications are now webapps or electron apps. From accounting software to music players, they are not native.

If someone botheres to make a desktop app, you either have proffeshionals tools or resource intensive applications like Adobe Photoshop, Blender3D, 3Dmax, IntelliJ IDE's and Games. None of them look native either!

Almost noone bothers to develop platform spesific apps, and native applications are dying. If we don't stop squabbling about native look and feel, we will get no native applications at all.


> Almost noone bothers to develop platform spesific apps, and native applications are dying. If we don't stop squabbling about native look and feel, we will get no native applications at all.

Well, unless you're talking open source tools and/or everythign within the sphere of desktop productivity . Then invariably your "consumer" desktop apps of choice are some mixture of GTK2/3, Qt, Swing, WxWidgets......

Granted, the different GUI libraries and applications using them tend to have _slight_ inconsistencies (GNOME 3 / GTK3 window titles versus everything else's window titles), but for the most part they're consistently themed, they render quickly, they behave the same way with the clipboard, mouse interactions, element focusing, keyboard shortcuts, accessibility functions......

So I have open right now LibreOffice Writer, Firefox, Evolution, many gnome-terminals, Transmission BT client, GNOME Files, GNOME Boxes... all of which look the same and there's no cognitive load spent switching between them, because they behave the same and look the same.

I can open up Inkscape and GIMP and Evince and KeePassXC and VLC and retain that experience.

Meanwhile, whilst still my IDE of choice, my PyCharm (so, JetBrains) IDE windows do whatever the hell they want (STOP STEALING FOCUS!!!), glitch out rendering, look completely different. And Spotify - gets all its points docked just for how it handles tabbing through UI elements. ("No, I don't want to tab through ALL of the Discover page, I want tab to cycle through the different UI elements, preferably not taking a painfully long time to reach "search".... Ugh fine, CONTRIBUTE TO MY CARPAL TUNNEL THEN!!!)

"Native" (as in, "consistent experience across the whole suite of desktop applications") toolkits still make it way easier for _developers_ to design applications consistent with the rest of the system.

Android and iOS UI toolkits serve same useful purpose. I tend to find that apps that are just a reactive web framework in a fullscreen frame are pretty painful to use. Like, wtf are you doing when I hit back!??? Why is this full screen splash form with two text boxes SCROLLING when I touch it???

tl;dr of my rant: Goddamn people stop trying to make your applications look the same on every device and let me use it how I like on MY device, for the same of a) my wrists and b) my attention deficit brain


I think Android and iOS killed the idea that you're ever going to be able to use a bunch of apps that behave consistently, because nowadays you're always using apps on at least two different platforms (phone and desktop). And it's far more important that Discord on my phone should look and feel like Discord on my desktop than having it match my other phone apps or my other desktop apps. So people have got over the idea that the platform is important and that apps need to match the platform conventions (rightly IMO; the platform is there to support the applications, not the other way around - of course it would be better if the platform makers could come together and agree some consistent cross-platform UI conventions that every app could use everywhere, but they didn't, so here we are).

If an app follows the UI conventions of the system it is running on, there is less cognitive overhead for users. However, with the rise of web apps users have at least become a little more used to interacting with a variety of UIs, though the problem is not entirely eliminated.

We've also eliminated a ton of crappy UI conventions and settled on some common paradigms in all platforms. I remember the four-layer-deep right-click context menus and I kinda shudder now.

There were also some really good ideas that I wish had caught on (I was a huge fan of focus-follows-mouse and I still use the X select-into-clipboard), but the general uniformity of UI patters nowadays is very much calming.


I really like the context menus in GIMP. Much less mouse travel than trying to hit the top of the window or screen.

True.

Main benefit to me is deflecting spurious input. All that Drive By Management.

Instead of explaining the history of ergonomics, the philosophy of ethnography, and our reams of data from usability testing, I'd just point at Apple's Human Interface Guidelines.

Like name dropping Aristotle in debate class.

More serious actors will try harder, lean in.


In addition to Swing also Qt and Gtk spent a lot of effort on this. Not to mention browsers reimplementing look and feel of native controls (not sure if they're still doing it). So it was wider than HN definitely. Other toolkits took the native route from the other direction (eg wxWdigets I think embeds the actual native widgets?).

Agreed.

I guess what I'm alluding to is something like CSS for desktop apps. I tried to tweak stock L&F a few times (not my choice) and I mostly failed.

Back in the day, there was a guy, Sven?, that crafted amazing L&Fs. I dimly recall he had one that was easily customized.


I remember Karsten Lentzch working in this space on the JGoodies project. I used some of his custom look-and-feels in a couple of projects... I think the had some tools to make layout easier as well.

http://www.jgoodies.com/home/about/


Bingo! Thank you.

> I guess what I'm alluding to is something like CSS for desktop apps.

JavaFX supports CSS styling.


Right you are. Wiki says since 1.2. It looks pretty good.

I just spotted JavaFX Script. Huh. This is almost directionally correct. So of course it got killed.

If you're curious what The Correct Answer™ is, imagine VRML-97 reimplemented using JavaFX Script like syntax.

Its wiki has a link to the Curl (programming language). That syntax is also directionally correct. But is also missing most of VRML's semantics.

There's also a link to the F3 programming language, aka "form fits function". Great slogan. Alas. Looks like a misunderstanding of Conal Elliot's Fran functional reactive programming language.

Oh well.

Thanks for the tip. JavaFX's Script w/ CSS was about 1/2 the solution. Maybe someday someone will loop back and harvest the good bits.


Didn't they introduce something like that with the Synth look and feel[1] in Java 7? Although with more XML.

[1] https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/...


You would have thought after 40 years there would be some standard GUI toolkit all the major OSes would adopt but stuff like swing, html, and TCL/tk are all we have...

and of course vt100 escape sequences for some reason.


> stuff like swing, html, and TCL/tk are all we have...

They are all you have if you don't know about FLTK, QT, Juce, GTK, wxWidgets and many others.


I guess not globally adopted but Qt to me is a pretty workable cross platform solution, nicely performant and reasonably easy to work with with great community support and problem googleability as well as pretty damn nice docs.

Unfortunately not easily usable with the JDK...


Exists? Yes. Actually usable? No.

Well, the idea between "major OSes" is that they try/do/offer different things. And the UI is large part of that. If they all have adopted the same, we might as well use a single OS.

That said, there should have been one, good, cross platform GUI toolking, and Qt, for various reasons, isn't it. The best we have is Electron...


I think an option could be GPU-accelerated drawing. It won't look native, but one can create a UI that performs well on just about any platform. Vulkan greatly improves the portability of such applications (compared to the OpenGL vs. OpenGL ES mess), and Skia has a nice set of primitives on which one could build.

It's also worth pointing out that creating a cross-platform API is better for new players than for entrenched ones.


You're just inventing your own toolkit, which is going to end in tears for everyone since you will have to recreate every component from scratch, rediscover all the interesting edge cases thereof, fail to reimplement some expected behaviors (triple-click text selection, drag-scroll, whatever), and break every accessibility tool in the process.

This is exactly what the linked article is proposing.

I feel the same way. I was writing a desktop Windows/Mac app using swing 10 years ago. The look and feel that came out of the box was fine. At first it was metal. It was a light blue with gradients to white on the buttons. Then they came out with Nimbus - I think that one was based on SVG or something similar.

No client complained about either of those. And at the end of the day you could always call a method to get the platform look and feel and it could look like Windows or Mac OS. I had a menu to change this in the app itself.

I never found the UI development hard. I was hand coding it in the beginning. I thought the Layouts were pretty straight forward (except grid bag which I never used). Eventually NetBeans had a decent UI designer and I used that.

I think the sloppy or slow UI's came from developers who never took advantage of the Observable / MVC aspects of the UI components.


Well, the author did not say, Swing etc. does not work. But that it is incredibly hard to make a UI with it, that looks good and is performant. And this matches my experience with java 10+ years ago, when I tried it out and left in horror ... for: flash.

(Flash had many, many drawbacks: proprietary, security, ... but it was really easy, to make something nice looking, that also run smooth - it was designed for that and later taken to higher level with flex)


When I wanted to write application, I used Swing and I didn’t find it horrible. Quite the opposite. I didn’t care about the looks, though, it was not a major concern. That was before Java 8. I could imagine that writing callbacks would be even easier with lambdas.

When people don’t laugh at Electron applications, I don’t know what could be wrong with Swing. Nobody cares about native toolkits anymore (what is native toolkit for Windows or Linux?).


Yeah well, " I didn’t care about the looks, though, it was not a major concern"

There is the difference. This post is for people who do care about the looks. (or do care, that their users care) Some users don't care, which is fine to serve them, what they want, but most actually do.

"When people don’t laugh at Electron applications, I don’t know what could be wrong with Swing"

People do not laugh at electron apps, because they use html which is designed for good looking. In other words, usually much better looking. It is just not performant, unless you use native modules etc.

And native toolkits are still a thing. Gtk for linux for example.

Personally I also care about the looks, but I prefer function over form, meaning I want a functioning app first and secondly it should look good. But I like to have both.


> And native toolkits are still a thing. Gtk for linux for example.

You mean Qt?


I don't know why you got down-modded so much. There is no official "native" toolkit for Linux; Qt is just as native as GTK.

> I want a functioning app first and secondly it should look good

One thing to keep in mind is that you want a functioning app first with less than great GUI but then you also want an app that is "skinnable" in other words it should be easy to replace the look and feel without having to touch the application code. CSS-stylesheets attempt to accomplish that.


HTML isn't designed for good looking. The default stylesheet for HTML is impossibly ugly. Heck look at HN, hardly a thing of beauty.

However, most people do a lot of work to make web sites and apps attractive. You can do that work with Swing or JavaFX too. I've done it before, it was fine, I ended up with a modern web-ish feel to the UI.


By now, html is totally designed to be good looking. Look at all the amount of work, that went into CSS and co.

Things that cost me a line in CSS, like text-shadow, probably would require me to implement a shader libary in swing.


In Swing, yeah. Swing focuses very much on boring business-type UI.

Not in JavaFX where such shaders are pre-canned and there's a CSS dialect too. I wrote my web-like app in JavaFX. It was no big deal.


gtk is not native (there are no native widgets on X Window System & family)

It's native to a user's desktop full of Gtk programs.

If there were a complete Swing desktop environment, Swing apps would be native to that environment. But even Sun's Java Desktop System was based on GNOME.


Electron performance is a lot better than Swing in terms of latency and startup time. Electron may use a lot of memory or whatever but that doesn't really matter; how fast it feels to the user is what matters. Meanwhile even basic Swing applications tend to come with a splash screen like they think they're Photoshop (remember Azureus, a freaking torrent client that took about 10s to start up?).

Yeah, your mileage may vary.

I was writing UIs in Swing 10 years ago, and we managed fine even back then, but our target customer is technical people so maybe our definition of "looks good" is somewhat easier.


I remember how horrible Swing was 10+ years ago I ran to SWT. Along with GCJ trying to compile everything into native executable.

And even SWT was far from perfect. It is one of those thing you can immediately tell by its looks, SWT, Swing, Linux, Mac , Windows. While the looks has been vastly improved, it still remain mostly true today.


"so maybe our definition of "looks good" is somewhat easier."

Yup, there is the difference. My target audience are common people, so I have to care more.


You really don't. I interact with "common people" every single day and they couldn't give less of a shit how the UI looks as long as they can do their job or whatever it is they need the program for.

The people who care about "looks good" are managers and designers because they never actually have to use the damned thing.


One of the best examples of this are old POS systems, which are mostly ncurses type applications. The people that use these fly around the interface so efficiently and are very productive.

Most of those old POS systems were actually either 3270 or (more likely) 5250 applications; i.e., block mode terminals instead of character mode terminals. While the difference between block mode and character mode terminals is a fundamental technical difference, that difference impacts the UI in two major ways: 1) Most interaction is local, and therefore quick. All of the editing, jumping between fields, and even basic validation happened on the terminal itself. It was only when you submitted your changes or loaded a new screen that the server would even get involved (much like a web form without Javascript); therefore, even in an installation with a lot of active terminals, these green screen applications would be incredibly responsive. 2) Every screen and application had exactly the same user interface. Even function keys were mostly standardized (ever wonder where F1=Help came from?), so what you learned in one place in the UI would trivially generalize to everywhere else in the UI.

> Every screen and application had exactly the same user interface.

IMO this is an extremely important idea and where I think the modern GUI went off the rails. I also, think it's gotten much worse with web applications.

I agree with the Raskins' that the fundamental issue with modern HCIs are applications. A common UI context in which to run commands would be more preferable in most use cases. I'm thinking of some mashup of the normal social media timeline with Emacs M-X functionality to run commands.


Well many of these do come with their own specialty keyboards, so there's that. The display is really just a display for these: all buttons are actual physical single-purpose buttons. No mouse.

Depends, if you have people needing to do a (unpleasant) job, sure, they also care more about functionality, than form. Nobody cares about a smooth animation, if he cannot get his job done.

But given the choice, they prefer the better looking one. In consumer facing apps much more. Especially younger people, used to shiny websites/html point out quickly, how ugly something looks. And then not use it.


There is a certain level of professionalism your UI has to reach for people to trust it. If your product looks sketchy, people will treat it as a sketchy product. And if you lock into a look and feel that is 10 years old, people may use your product but they're going to be surprised if it behaves in the most up to date fashion.

> In consumer facing apps much more. Especially younger people, used to shiny websites/html point out quickly, how ugly something looks. And then not use it.

As far as I can tell, this is a narrative that only exists in the heads of people who never have to use the thing they are insisting "look good". Sales people, managers, developers, etc.

I will accept that I'm wrong when I either experience it in the real world for myself or see some actual evidence.


"I will accept that I'm wrong when I either experience it in the real world"

Well, here in the real world, (because of the need of Windows) I just recently started to use Notepad++ again. It really pains me to do so. The only way to tolerate it, is by removing all UI and only keeping the text. But even then some ugly, contrast breaking window pops up, when I use search etc.

So I will likely switch to sublime text (even though I only have to work on windows sometimes). Simply because of aesthetics I choose a solution nicer for my eyes, when I have the choice, which I do.


Anecdotally, a significant number of recent criticisms towards Emacs and vim are that they’re ugly compared to VS code — that seems to be a solid counterpoint to your argument that among users, aesthetics don’t matter.

The people who care about "looks good" are also usually decision makers and funders, so yes, it does matter - regardless of your opinion on whether it should or shouldn't.

If we're talking about appeasing the bullshit gods, sure, there might be something to that but my experience is that they talk about "looks good" a lot but when push comes to shove they'd rather have something that works.

Case in point: people still use Windows, and I've never had anyone tell me it's because it looks good.


Certainly a good counterpoint! Now that I think of it, I've never heard a single person tell me they use Windows because of good looking UI!

Unfortunately the bullshit gods usually have more influence than should be allowed. But making something 'look good' in a sprint demo where the CEO is present potentially releases a lot of pressure and gives the team more time to build something that works.


Funny. We just built it new platform in gwt. It's an unashamedly retro approach but there's a lot to be said from using Java on the front end as well as the back. Productivity was really high.

Indeed. JavaFx is not to slow to build RealWorld GUI Desktop Apps. Here is an example of a Desktop CAD/CAM Application for Digital Dentistry written in Java using JavaFx and OpenGL. It is smooth and performant, otherwise noone would use it.

https://youtu.be/36dWOXyQWmo?t=124


Do you know how could they integrate OpenGL context with JavaFX?

I tried to do the same few years ago, couldn't find a reliable way.


I've wanted to use Swing (I kind of like the old-school metal L&F) but my issue with it is the glitchy-looking result, the opposite of Wayland's "every frame is perfect" motto.

When I tell Swing to display a simple window with some simple widgets, it will

1. First display the window in some random place on the screen,

2. Then move it to the position I actually specified.

3. Draw all the widgets with a slightly wonky layout,

4. Then erase the widgets it just displayed and redraw them with the correct layout.

This happens in every Swing app I've ever used when opening a window, even IntelliJ. (The glitching window position is not always observable.)


Do you plan on trying JavaFX?

Sigh. I had such high hopes for it, and then Oracle abandoned it.

But we are trying it, and opinions (internal to my company) are varied. Some people like it, but I don't. Because (a) it has missing functionality here and there (b) it still has a long road to go to become battle-hardened (c) I don't see any of the current supporters having deep enough pockets to fix (a) and (b)

So we're taking a mostly wait-and-see attitude.

But we have an existing deep and wide investment in Swing in our products, so our risk profile is probably somewhat different to yours.


> Sigh. I had such high hopes for it, and then Oracle abandoned it.

As far as I'm aware, it was only pulled from the JVM into a separate dependency, as did several other components, in order to keep the JVM slim. Are you saying development on it stopped altogether?


Oracle has mostly disbanded the team that was working on it, leaving only one or two staff to manage community contributions.

There are however, a couple of small companies, and some individuals using it, and providing contributions.


Javafx is very much alive at: https://openjfx.io/

Gluon also provides builds for LTS and latest here: https://gluonhq.com/products/javafx/


Sometimes a setup like that is the best setup possible, no ambitious team trying to make their mark by replacing something that doesn't require replacing or that they can't replace well enough. I doubt that JavaFX would have more impact if they put a team of dozens on it (or, shudder, hundreds) but they would surely make life harder for those who still build on FX. A larger team might have already declared javaFX dead entirely, urging everyone to port to some exciting new javaFY and losing many of the remaining users in the process, without attracting any new ones. Arguably Swing to FX was already a bit like that.

As far as I know Gluon has taken over the development of JavaFX.

It's not easy to get JavaFX working for development and it's tricky to get it bundled properly for deployment. I can see why they wanted to split out big parts of Java but I think it does discourage developers from using the library.

There are lots of fast, usable JVM gui applications.

Some OSS examples:

http://www.sweethome3d.com - This one has been the one app I've recommended to people outside the tech bubble! It also focuses on graphics and 3d.. really deserves to be showed off more often

http://xmind.net

https://dbeaver.com/

http://www.mucommander.com/

http://www.jedit.org

What they have in common is that they are old project - often more than 10 years old and are not on Github. Goes to show how important hype and trendiness is in our industry.

edit: fixed formatting


The JetBrains suite (ie IntelliJ, Datagrip etc) while not open source, are a testament to what can be done with JVM based GUI applications.

Have you ever used the merge tools? So dang cool.


IDEA still has a horrible GUI in my opinion. All sorts of weird subtle bugs relating to the very fundamental UI interactions that make the whole experience very frustrating. The main one I remember is that certain buttons in the UI are simply unreliable - depending on what processing is going on (sometimes if nothing heavy is being processed), certain buttons in the UI will not respond when clicked. I used IDEA for years and very often had to click a button 4-5 times until it would activate, especially while using the debugger.

If the UI toolkit can't get a button right, it is completely broken IMO. Even including intelliJ products, I have never used a Java GUI which was good.


I've never experienced anything like that in IntelliJ, and I've used it everyday for years now. Granted there are bugs especially around big releases, but I've never seen any UI bug like you described. Everything is always smooth and responsive.

I just fired it up to see and it's still kind of there. For example when loading a project, there's a popup progress bar and the UI kind of janks around while it's loading. If you click anything in the UI while that's happening like a menu, the event is lost.

OK - it's loading so that's not unexpected. However my previous experience was that the same thing would happen to the UI at all sorts of surprising moments when other processes were ongoing, such as linting or using the debugger. Kind of hard to reproduce without a large project at hand though.

Then I had to stop testing and SIGKILL it because the whole application got into an infinite loop of NPEs in the UI event loop of all places!

I too experienced using intelliJ for many years and this seems largely in line with what I remember.


The stop/run button in the Run pane often doesn't work for me - i mouse over, it doesn't highlight, and clicking it does nothing. Minimise and maximise the pane, and it works fine.

Sounds more like an IDEA bug rather than a Swing bug. I've implemented an editing tool (realtime video generation parameter editing w/ feedback from the generator) that really has a lot of issues.

Part of them because i didn't fully understand Swing when i began the project and partly because synchronizing GUI's to another live process is a quite error prone task.

A debugger process is almost certainly not living in the same thread as the Swing UI of IDEA so this almost surely more of a thread synchroniztion issue rather than Swing issue. (You really don't watch to do any cross-thread touching with Swing apart from for a very limited set of components built for this).


Yes it's certainly something to do with threads. Still the way it manifests is weird. For example sometimes in apps like Chrome or Firefox the tab bar will freeze momentarily while the UI is hung waiting for something, however if you click something like a tab close button during this period your click will be processed once the UI un-hangs.

In intelliJ it was like whenever the UI was not immediately responding to mouse events, it would often just lose the event instead of it being correctly processed once the UI thread was freed up.


Chrome/FF in this case has an UI thread that becomes unresponsive for whatever reason and doesn't empty it's message-queue (that contains the mouse/keyboard/etc events).

In the case of IntelliJ there is probably some of their code accepting the event and then probably has some ad-hoc message passing by setting a field that is polled by the receiver thread under the assumption that the receiver always runs faster than a human can act, however as soon as that assumption is broken by some pause you get what you describe.


IDEA Community edition is opensource: https://github.com/JetBrains/intellij-community

Skija (the graphics library in TFA) is in the JetBrains organiation... https://github.com/JetBrains/skija/

The JetBrains merge tools are the best ones I've found!

I have it configured as my git mergetool

The only problem is it takes absolutely ages to start up, which is maybe a JVM thing

I wish there was a way to have git pass all of the conflicting files in a merge to the mergetool at once. Instead of having to wait for JetBrains to load up for each individual file and close after each one :(


JVM apps can start in <100 msec, and IDEA has a 'lite' mode now where it's more like a text editor. That starts very fast.

IDEA is slow(ish) to start because it's an IDE so it's loading tons of plugins, a project database etc. Though actually recent versions only take a few seconds on my admittedly high end MacBook.


There's also some AOT options for the JVM to get a faster startup, along with -Xquickstart. I definitely agree with the "you're loading an entire IDE" statement.

I wish I could launch just the diff interface without all those plugins then

TBH I never got on with PyCharm and still use Sublime Text... but I keep PyCharm installed just for the mergetool!


That's what lite mode is. Check it out!

I do it the other way around, I let git write the default conflicting files. And then switch to IntelliJ, press Ctrl-a and type "resolve", press enter. And voila I am in IntelliJ's git resolution windows where each conflicting file is listed.

> I have it configured as my git mergetool

How are you doing this? I haven't seen any merge tool, let alone a standalone one, in the JetBrains toolbox. What am I missing?


You invoke it with "idea.sh merge <left> <right> <base> <out>". TBH, I don't think it's anything special; I've been using p4merge for years.



I use IntelliJ for work every day and I agree, so many of its features make work so much better.

Yes, but they are also an example of why people don't like Java UIs.

I.e. the amount of UI problems you have with it when using a tiling wm or wayland (or both) are just sad and make it unusable. Other widely used UI's might also have problems but at least are somewhat usable under wayland and/or tiling wm.

Ironically many of this problems go back/are rooted in to AWT...

In the past Intellij did work if started directly by x (without a wm) which was pretty cool for some very very neach use cases, but sadly (through reasonably) this isn't the case anymore.


Just out of curiosity, what issues do you run into using them in a tiling WM?

Context menues not being at the right position, directly closing after opening (so fast that you can't really see it) as well as menu items sometimes not being selectable.

Especially the quick command/search menues doesn't work at all and context menues sometimes don't work either.

(Edit: And context/popup menues not working is the main theme of problems with Java GUIs, hence my parent post, also setting the "magic" no-reparenting env variable doesn't fix it)


I can second these issues using i3 and arch. I've had subtle issues like these in Ghidra and when I once tried Armitage (I wanted the Hail Mary feature), it was so messy I've never used it since.

Most of the hate towards electron is only because of its resource usage problems and not because of its capabilities. Vscode is it's testament for capabilities. Jetbrains suite is great but they're not resource efficient in any way!

If the JVM based apps do not yield a significant performance benefit then there is no point in going after that.


It's not only resource usage, but performance in general. I can feel lagging when typing slowly in VSCode editor, even in plain text files without even trying autocomplete or any IDE feature. IntelliJ IDEA doesn't have any lag, Eclipse too, and both offer more IDE capabilities than VSCode.

The article covered another factor:

>The second is the DOM. It is a horrible collection of hacks that make simple things hard and hard things impossible. I have thought many times “if only was I drawing this control/layout directly, I would’ve finished hours ago.”

As a user of electron apps there are clearly limitations on what the UI can do as a result and the style of rendering it is clearly webish.

Another issue I keep on seeing with web based apps, moreso on android, is they seem utterly incapable of dealing with the slightest network non-connectivity. The UI tends to freeze.

I do take your point entirely on the fact that perhaps java's inherent performance limitations might result in a fairly comparable poor experience however.


And the DOM, and the size overhead and it's JS/TS and some other parts from dev (i.e. not user) perspective.

Through tbh. I don't see much reason to spend time for a Java UI framework, Java for desktop is just kinda annoying and somewhat even more dead then Java for servers (which isn't really dead tbh).

Through I guess idea/Intellij would love to replace the low level parts with something which works more reliable.


Yeah the reasons for choosing JS/TS don't have to be stated from developers' perspective because its the goto tool for new products nowadays.

Also I don't think the desktop app market for java is small in any way. But if there's no difference between electron and JVM UIs then there is no incentive for teams to switch.


But what about the teams coming from classical desktop application development. Perhaps they don't want to switch to Electron-based web development.

Big plus for SweetHome 3d, I designed my new bathroom with it (nothing fancy, just some render to get the idea of how various options could look like, but given how bad I am at those things it was a great success!)

Dbeaver is certainly not fast. It requires several seconds to start on a machine with a Core i5, 32G ram and a NVME SSD!

In fact VSCode starts faster.


Start time is not a great measure of overall performance. Also you are comparing two very different types of applications.

A text editor that can be extended vs a platform application is the same argument we've been having about vim vs emacs for years.

DBeaver is an incredibly powerful application that had allowed me to work in Postgres, Teradata, and Oracle databases for years. Could I do the same kind of work in VSCode? Absolutely not, unless I wanted to build out an entirely new interface on top of VSCode. By the time that work is done it could be equally slow to start up. DBeaver has an absolutely massive feature set tailored for database work and it has to load all those plugins at some point.

Another counter point is VSCode with java-lsp could never handle the 300k loc code base we developed on, where intelij and eclipse do just fine. Yes, they startup slowly, but at least they provided meaningful and fast autocomplete without the need to wait for the language sever or VScode to unfreeze.

Again these are purely anecdote, but please don't purely judge an application by it's startup time if it saves you time in the end.


One thing I've noticed is I don't care about start time if I'm going to be in one app for several hours, but if I'm doing a lot of switching between apps, without one app taking my primary focus, I become very sensitive to start-up time.

I also think the optimizations for high performance with a relatively small amount of data are fundamentally different than the optimizations for high performance with a very large amount of data, I have not really seen any GUI approach that scales smoothly from small amounts of data to large amounts of data without some complexity on the back-end


I talked about speed not usefulness or features since parent said:

> There are lots of fast, usable JVM gui applications.

I used VSCode as an example because it's touted as the fastest electron app.

Now I have no idea how to benchmark DBeaver once it's running but since my use case is to launch it once in while to run a quick SQL query, startup time is important for me.

For years I have said I need a kind of SQL pad: a native app, that launches ultra fast, directly shows me the tables once connected (hide all the complexity of the DB) and let me run some SQL immediately. I guess I'll probably have to scratch my own itch once I find the time.


I recently came across Beekeeper Studio in a comment here on hn, and I really like it so far.

I generally use pgcli for talking to postgres, and I occasionally need sql developer for Oracle - but with Bk i might standardize on it for ms sql server, postgres and sqlite.

It's foss and electron. That it's snappier than sql developerto start isn't saying much... I guess.

https://www.beekeeperstudio.io/

https://github.com/beekeeper-studio/beekeeper-studio

https://www.pgcli.com/

I tried ms azure data studio or what it's called, and I think Beekeeper is a good alternative. It doesn't do all that sql server mgmt studio does - but then it also doesn't need to run in a windows vm..


> I recently came across Beekeeper Studio in a comment here on hn

me too :) I installed it but didn't connect to any DB yet. Startup time is certainly no better than DBeaver though.


A co-worker that lived in his terminal used jsqsh[1] for simple queries to an Oracle DB when he did not need DBeaver. Jsqsh appears to no longer be maintained and I'm not quite sure how fast it is, but it still might be worth looking into. There is also usql[2] that you might be able to build something on top of.

[1]https://github.com/scgray/jsqsh [2]https://github.com/xo/usql


Table Plus has native versions for macOs and windows https://tableplus.com/

Tealpod Image Compresssor for MacOs is built using JavaFX. https://www.tealpod.com/compressor/ Windows version is built using .NET, C#.

Interesting that they have two versions, when the JavaFX version should be cross-platform. Is it because they built the .NET version first?

Dbeaver is really ugly, though. To the point of being unusable due to aesthetics, like many Java apps.

How aesthetics make it unusable?

mucommander is on Github

>There are lots of fast, usable JVM gui applications.

Debatible, argueable.


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.


From the article:

"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.

This is directly addressed inside the article, in the last sections.

[flagged]


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."

https://news.ycombinator.com/newsguidelines.html


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).

> Just don’t, like, draw something that looks like a GUI in it.

I think you've got the wrong end of the stick. The author isn't suggesting anyone do this.

But most apps need to do some drawing of their own - if they're a charts library, or a CAD program, for example. Then you need a library like this.


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”.

Ehmmm, did you actually explore any links?

https://www.jetbrains.com/lp/compose/ shows a code editor prototype.


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:

- a graphics library,

- a window/OS integration library,

- a UI toolkit.

--- start quote ---


Is your central complaint that a "graphics for the JVM" library is not a full featured "UI toolkit for the JVM" library?

A bit of context may help.

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.


You're right, that does help, alot.

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.


See the end, the section: What’s with the rest of the puzzle?

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.

> The second is the DOM. It is a horrible collection of hacks that make simple things hard and hard things impossible. I have thought many times “if only was I drawing this control/layout directly, I would’ve finished hours ago.”

I think this betrays a lack of understanding on the part of the author of how to write good web components. Yes, the DOM is tricky at first, but that's because it's trying to support things like resizing windows to arbitrary sizes.

I don't even understand what he tries to say with "draw the control directly". In component-based library, this is exactly how you would work. Put your component where it needs to be, and boom, you're finished (just like in all frameworks this is a lie, you probably still need to tweak).

I don't in general buy the argument that the DOM is low-performant and low-quality. Lots of great and performant UIs have been built on the web platform.


Let me give you an example, the DOM is missing a decent dropdown component. Some will say that they can make a cool dropdown in 2 minutes with 20 divs and some js and css, the issue is this 2 minutes components have lot of bugs and missing features (accessibility, keyboard supports, missing events) and then if you need the same dropdown in other section but you need to add 1 small thing you duplicate it again.

For comparison in GUI toolkits you use the existing feature complete dropdown. And if you need more customization you extend the dropdown and override it's render/paint function and you can painted as you want. What I liked about this powerfull GUI toolits is that most of the time you used the built in stuff so all application look consistent and only special apps would create custom stuff.

I wish browser makers would focus on improving the existing DOM elements and adding a few more so we could use native ones instead of having to implement custom shit because the designer wants the component to look in a specific way but you can't CSS the native element to get the result.


It’s good that you mention accessibility, because TFA does not. Nor does the Skaija repo, and nor does the repo for Jetpack Compose for Desktop [0], JetBrains’ higher-level UI kit based on it. I think it’s a mistake to suggest that “native UI toolkit” implies “feature complete”.

[0]: https://github.com/JetBrains/compose-jb


Skaija wouldn't really be the place for accessibility features (except for maybe provide access to color-blind filters?). It's an important feature, though, and I hope Jetpack Compose gets better at it.

Desktop Compose is in alpha. I don't think it's appropriate to use that as evidence of feature completeness.

Another example is trying to implement a text-editor in the browser. Yes it can be done, but the standard component for text-editors is TextArea which is not much to write home about.

An example big issue I faced creating my own editor was getting the caret follow my mouse-clicks and key-presses. Then trying to highlight matching parenthesis. I know it is doable because I did it but I had to spend a lot of time on it and I'm not quite happy with the end-result. A standard high-quality text-editor component should be part of the web-platform but is not.


Yes, I had to do something similar using the contenteditable, a giant issue is that the browsers differ a lot(I had a lot of issue with the selections/ranges differing a lot)

> Some will say that they can make a cool dropdown in 2 minutes with 20 divs and some js and css

Isn't there already JS libraries to do that? If so, doesn't it boil down to the same issue as traditional OO UI toolkit, where the abstraction must be extremely precise to allow for any sort of customization?

> For comparison in GUI toolkits you use the existing feature complete dropdown.

Aren't you making the assumption here that GUI toolkits necessarily bundle a perfect implementation of this widget? Why would that be only possible for native GUI and not for Web UI?


The problem with existing libraries that give you a dropdown is that you have not one but many such libraries and some will not be compatible with what your project uses, some are missing the feature you need, some are bugged. As an example the Search input in YouTube has a dropdown with suggestion, that dropdown got stuck on for me a few times , clicking outside it did not make it hidden, I had to reload the page. So google developers are incapable of creating a basic dropdown that has the feature where you can type and shows you some options. If there was a built in powerful enough dropdown then YouTube could have used that and not invent it's own broken version. My point is give us native components as powerful as Qt,Flex,WPF , React, Agnular and others could use those or if they want can use DIVs or canvas , I don't want to remove you the option to use React or whatever.

The existing toolkits are not as limited as you think because you can most of the time override them and do whatever change you want , most of the time though you have enough built in customization that you don't need to do advanced overrides (I do not mean only visual customization, for example a dropdown can give you the option on how many items would be visible on the dropdown at once, a DataGrid can give you option about what columns are resizable, sortable and you can specify if you want a sort function for a column. And about DataGridView components, the native ones are implemented smart and can hold a million rows and have no performance hit because are smart enough not to create million GUI elements.

>Aren't you making the assumption here that GUI toolkits necessarily bundle a perfect implementation of this widget? Why would that be only possible for native GUI and not for Web UI?

Desktop toolkits are not perfect so if your designer asks you for super extra fancy stuff you can either extend and existing one or you can create it from scratch but for visual stuff just changing the paint/render function would be enough.

For WebUI, let's say I need a good dropdown, calendar, and DataGrid where do I go and get this components? If you say bootstrap those are too basic, if you say some React stuff maybe I am not suing react, if you link me to some Angular version N stuff maybe I am using N-1 version etc.

I think if you ask 3 developers to go and find me an X component for my framework Y I would get back at least 3 different results.

Other issue with non native components is that if you do not read the code you might not notice bad quality, components that do not clean after themselves or that run code each time you move your mouse around the page.


> then if you need the same dropdown in other section but you need to add 1 small thing you duplicate it again

Not really. That's the point of making components in React/Vue/Svelte/etc, you can create reusable modular parts.


Can you today make a component, use it in 10 places in your project and now if you need to add one extra thing for the 11th place can you "extend" the existing component so if you fix a bug or add some new event in the old component the extended one inherits it? I know in OOP toolkits you can override any public and protected functions and add your little stuff on top but I am not sure if you can do it in React without cloning the code and modifying it.

As an example you say have a DataGridView , a giant component with a lot of features and you need to modify something, can you do it in React using inheritance like functionality and not risking breaking anything where the component is already used ?


Instead of using inheritance you'd use composition, but yeah you can do exactly what you're describing.

Just right now I'm building a component that abstracts filtering and sorting for lists of items in Svelte.


If a designer gives you 2 images to use for a radio button can you do a correct radio button in 1 minute (no third party libs?)

By extending a RadioButton and overriding the paint method I can do it in 1 minute. The component would still be a radiobutton, same interface, same events,same keyboard shortcuts, same accessibility, focus/tab-order behaviour.

In React you would start with a div, put 2 img inside it and implement the toggle logic, After that you need to add the events, the keyboard shortcuts, the tab ordering, focusing, accessibility.


I mean I would not just add images as radio buttons but if that's the criteria you're going for: Yes, it would only take me a minute and it would have all the events, keyboard shortcuts, tab ordering, focusing and accessibility.

Apart from the fact though that your understanding of a toggle on the web is switching visibility on images instead of building the button how the design wants it and not unnecessarily load images shows that you not only sound quite like an ass but are also so stuck up that you think your understanding is good enough to compare your experiences.

Hint: It's not. Get over yourself and maybe put on a gentle tone next time you're trying to make a bad argument.

This is also pure gold that I can't believe you actually would do

> start with a div


I apologize if I expressed myself aggressive, my comments were not addressed as an attack to a specific person or framework.

Let me know about how would you implement it in 1 minute, I want to know because it seems I missed this method you are speaking of and I really need to learn it.

What was such terrible about "start with a div" all components I seen so far start like that see for example https://getbootstrap.com/docs/4.0/components/dropdowns/

Honestly I am not sure what triggered you, I had a nice dialog about what is missing with the DOM , the other comment acknowledge my point and I am confused by your aggressive tone(english is not my native language so did I used the wrong word or what triggered this response?)


Right, but the problem you're describing is not the failure of React to compose components, but the fact that in-browser elements are not React components.

If you had a library of React components, and it had a BaseRadioButton, if properly designed you could use it to compose other components (radio buttons, forms, etc).


Yes, my issue is with the DOM itself and the browser makers that add new stuff all the time but they have not added any major improvements to the included elements and add the needed one.

Part of the solution would be to have Mozilla and google check what developers need and add that but IMO there is a giant chance a Google developer will invent yet another framework instead of working on adding more css support for the "select" or scrollbars.


I think the point was: Chrome has as much lines of code as Linux with all its drivers and still has no decent dropdown built in. Not that it cannot be built.

If you override the render/paint function somewhere, would you not have to do extra work to improve accessibility again?

It depends. Say there is a Label that should show some text and a crazy designer asks me to have the text rotating and jumping and also be super light gray and ahrd to read, the component could still report back to accessibility framework the actual text and you could have a better experience then a regular user.

Custom rendering is not most of the time painting on a canvas. A simple example , you have a Dropdown, each item is rendered with a simple component that is something like

<text>item.text</text>

and you might want to change the render function to be

<icon>item.icon</icon><text>item.text</text>

I think ATM you still can't use the HTML select to have a dropdown with the countries and the flags or a dropdown with the fonts and each font it is painted with it's own font family, or customize the numeric spinner arrows or scroll bars colors.

Again , I prefer using native widgets, but I am forced to implement designs and I have to replace a native component with a pile of netsted divs,js and css.


Oh, I see what you mean. I was thinking about the case where you're painting something completely different than the semantic information but I guess that's rare.

You're right, in HTML you have to fall back to elements without accessibility features pretty quickly if you wanna customize a native component. There are some features that one can use to restore accessibility like ARIA but yeah, it's not great.


Not if you're just making it look different, because the component already hooks into the right APIs to expose itself to screenreaders etc.. Of course if you're doing something completely radical you need to implement accessibility yourself, but there's more flexibility to customise existing components as little or as much as you like.

No, desktop accessibility APIs are basically about exporting a labelled semantic tree to screen readers. As long as your dropdown is still semantically a dropdown with items, etc, and responds to basic commands, it doesn't matter what it looks like.

I will just say I agree in my own words "the DOM sucks for user interface development". I don't know why people are always so quick to defend it, or insist on being ardent apologists for it. It's a crap foundation for what we've been building on it for decades. It was never intended for this.

Yes, I am forced to use is, as we all are. But, I tell you, I miss Swing and actual GUI component libraries that were designed, and implemented, from the ground up to be used as GUI.

I could rant until the end of my career for this mistake of a path we all took in the 90s. HTML/Hypertext was a game changer. But, bastardizing this implementation into what we have to deal with today was a total and utter mistake.


I wouldn't say it's a crap foundation but it's the wrong foundation.

DOM, CSS and the way they interact with JS where designed for mostly immutable "documents" with mostly but to complex design.

Then it was bend and extended to somewhat extend somewhat more complex designs and more interaction.

That step was repeated again and again until now where is used for application graphical user interface instead of just displaying documents with some forms in them.

The foundation is fundamentally unsuited for the task it's used for by now.

CSS might seem simple but has crazy amounts of hidden complexity and until recently lacked trivial/simple ways to do some layouts common for GUIs but unnecessary (and bad) for displaying documents.

In recent years thinks have gotten better, e.g. CSS grid makes GUI layouts SO much simpler, but still the foundation is broken.

As consequence many of the promises the foundation gives are in practice often broken, too (like accessibility, like free resizing and zooming which often doesn't work correct, like cross platform as web apps are often designed for chrome relying accidentally on chrome specific behavior especially wrt. CORS, ...)


Could you give some examples of what are the problems with DOM and how do alternatives look like?

It's been some years that I don't do anything web so I'm not sure if I'm familiar with its problems.


> Lots of great and performant UIs have been built on the web platform.

still waiting to see them, at least for performance levels comparable to 2007 desktop apps


With the DOM, can you extend the default text input component while keeping the default behaviors, like when inheriting/subclassing a component for normal GUI toolkits? For example accessibility.

Also, does the DOM have a ListView/TreeView?


> Lots of great and performant UIs have been built on the web platform.

This must be some strange usage of the word 'performant' I wasn't previously aware of.


> Lots of great and performant UIs have been built on the web platform.

At the risk of simply mirroring dmitriid's comment, and without wishing to come across as snarky: which ones?

I don't think I've ever seen an Electron app that couldn't have been implemented in C++ to run appreciably faster and use at most a quarter of the memory.


> I think this betrays a lack of understanding on the part of the author of how to write good web components. Yes, the DOM is tricky at first, but that's because it's trying to support things like resizing windows to arbitrary sizes.

This statement betrays the commenter's lack of understanding understanding of both limitations of the Web model and the freedom afforded by almost every single one of UI libs and frameworks.

> I don't even understand what he tries to say with "draw the control directly".

Aaand here it is: "I don't understand".

In a GUI framework/lib you usually have the ability to skip the provided primitives and draw whatever you want directly. A framework/library doesn't provide a control you need? You just draw it yourself.

So, instead of re-inventing, poorly, a virtual list, or a calendar, or a customisable drop-down with a few thousand divs, z-index issues and layout thrashing, you can (relatively) easily implement those controls yourself. At easy 60 or 120 fps.

> I don't in general buy the argument that the DOM is low-performant and low-quality. Lots of great and performant UIs have been built on the web platform.

Name a few, please. And when you look into those "performant UIs", you'll see on or more of:

- skipping the DOM entirely and building everything on top of canvas or webgl

- going through great pains to: avoid mutating DOM, avoid repaint/reflow (which can happen by simply querying the DOM [1]), reducing the already laughably small amount of updates even further to prevent DOM updates, layout thrashing, JS GC pauses etc. etc.

And this will still not come even close to, lets say, displaying a million objects on screen at 120fps (any modern game engine), or any significantly complex UI layout (any professional app).

[1] https://csstriggers.com and https://gist.github.com/paulirish/5d52fb081b3570c81e3a


I don't think you're wrong just that the discussion warrant more nuance and less ego. On the the comment...

> You just draw it yourself.

This is disingenuous. It might be ok in Games not to have decent interop with the OS but for productivity tools, it is a requirement.

Which means you need to implement OS native interop (for multiple DE's in linux perhaps), accessibility for screen readers and you need to be smart with your rendering because having a function called 60+ times a second is a surprisingly big foot gun. All this across 2-3 very different (and currently diverging) operating systems.


Rendering something natively in OpenGL (or using a lightly-wrapped framework around it) is usually much more performant than fiddling with canvas elements or CSS, so I don’t think it’s a footgun. (And OpenGL is quite cross-platform if you stick with older versions.) And since browsers these days also have all sorts of incompatibility issues, the merit of “write JS once” seems to be dwindling a bit... (although that’s becoming less of a problem when Chrome is becoming the de-facto browser)

> Which means you need to implement OS native interop (for multiple DE's in linux perhaps), accessibility for screen readers and you need to be smart with your rendering because having a function called 60+ times a second is a surprisingly big foot gun. All this across 2-3 very different (and currently diverging) operating systems.

Yes, you have to do all of that, and I never said it was an easy task. That is, it's relatively easy compared to the web. This task is close to impossible on the web, especially if you want decent performance.


> In a GUI framework/lib you usually have the ability to skip the provided primitives and draw whatever you want directly.

HTML5 canvas?


Literally in the very same comment:

--- start quote ---

... when you look into those "performant UIs", you'll see on or more of:

- skipping the DOM entirely and building everything on top of canvas or webgl

...

--- end quote ---


Yeah, the whole of the bottom of the post strikes me as off base.

I think the author is trying to get to a wonderful future but their heading in totally the wrong direction.


I'm continually impressed by the stuff that comes out of the Clojure community. They really seem to punch above their weight in terms of useful output, novel ideas, interesting projects/products. Much more so than say Scala or Kotlin which enjoy a lot more industry adoption.

Tonski specifically has always wowed me with his work, I'm eager to delve deeper into his take on UI.

What's wrong with Java 2D, Swing, and SWT specifically, rather than being old? Saying that IntelliJ IDEA is the only Swing app that doesn't suck isn't really an argument to fragment the Java desktop space even further when new desktops apps (Java or otherwise) haven't been developed for well over a decade.

SWT had a lot of weird cross platform quirks which were unbearable to diagnose, it's been 10+ years now so I can't recall all details, but every time I tried under the premise of the better components, as the UI got complex, there was no other solution but escape back to Swing, where the tooling and facilities around where miles better.

SWT is not even mentioned, being literally the other big elephant in the room (Eclipse). Grosso modo it does not look like due diligence has been done...

The author also lumps AWT, Swing and JavaFX together. They're different, and some were created to solve issues others didn't address, and/or improve them (never mind that JavaFX is its own beast, and is quite different from the other two, which are relatively close). But they're all GUI toolkits, and they all suck doesn't make sense.

I'll take a minute here to plug Defold (https://www.defold.com). It's a game engine with a dedicated IDE for building games. The IDE is built mostly with Clojure and JavaFX.

Of course I'm biased, because I helped build the IDE, but I think it looks and feels great. It has a 3d modeling view that does pan, rotate, dolly, all at somewhere between 30 and 60 fps.


It looks good, but the pictures are a bit hard to see :)

> They were so significant that only one company managed to build a decent-looking app in Swing [IntelliJ IDEA]

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.


The omission of SWT made it very hard to read for me. It's really only relevant for the introduction (on the low level that a skia binding is, SWT is surely just going through AWT), but echoes of the omission still bounced around in my head in the later bits, distracting me. A quick dismissal (good or not) would have made the rest much easier to read.

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.


> SWT is surely just going through AWT

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.)


>Also, I suspect one of the things holding back Java desktop GUIs might be that they're often clumsy to distribute.

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.


> it still looks Java

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...

[1] https://en.wikipedia.org/wiki/Excelsior_JET


And about your edit, it's true of course, this is an issue. If you bundle the JRE feels wasteful and if you don't it feels uncaring for the less technical. Didn't JavaFX, beside being "Swing 2", consist of some native launcher component that would connect with an installed JRE if available (and sufficiently modern) and guide the user through download/installation if not? Memories are faint.

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.


> Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI.

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.


> 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?

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.


The whole new GUI toolkit in question is Compose Native and that's not entirely new (only the desktop part is). Literally millions of Android devs would already feel more at home with it than with any other desktop UI toolkit.

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.


JavaFX might turn out to be a winner but it's still partly proprietary and is still transitioning from Oracle to the OpenJDK community. There's good reasons for it having little adoption.

> I'm not convinced that JavaFX is too slow for use in real-world GUIs.

I would like to have an opinion on this myself but I've yet to find a JavaFX application in the wild.


We do use JavaFX in an app for our customer. The application is not public, however.

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.


My experience as well. JavaFX proved to be really fast for us (internal tools as well). Used to control equipment (live) or do calculations. And we distribute in a <200MB package jre included (modular builds), installs on a fresh windows or linux with no other download. For people that already have a jdk installed, i think we are around 100MB. There has been a lot of work on making "small" distributable java apps in the recent JDKs.

I wrote a JavaFX application in Clojure using CLJFX. It's fantastic and native-speed when you do things right

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


The end of the article points out how this graphics library is getting used as part of a UI kit. The article goes full circle, it talks about the three different components of UI technology up front, and then shows the other two components near the end.

I tried JavaFX recently and within seconds all I could notice was jacked up font rendering.

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.


Different JVMs have different font rendering settings. Try Zulu.

Not my project but this video seems to imply that it has no problem with performance whatsoever:

https://www.youtube.com/watch?v=7Hai7cavmUY


> Like any other JVM library, it’s cross-platform. It runs on Windows, Linux and macOS. It’s as simple to use as adding a JAR file.

Well, not exactly. https://github.com/JetBrains/skija/ is 30% C++ and of course requires native builds: https://packages.jetbrains.team/maven/p/skija/maven/org/jetb.... If you are lucky, Maven simply hides it from you.

UPD: no, it doesn't hide it. See https://github.com/JetBrains/skiko/blob/master/skiko/build.g... and search for 'lin'/'mac'/'win' and see for yourself.

UPD2:

  @-moz-document domain("tonsky.me") {
  body {
      /* surovyi background color off */
      background-image: none;
      background-color: hsl(0, 0%, 85.9%);
  }
  }

Is this a problem? We're always going to need native blobs to interface with the OS. The JVM can package these native libraries within the jar so for the application developer it is indeed as simple as adding the jar file to your project.

> We're always going to need native blobs to interface with the OS.

Ideally we won't when the JVM gets an FFI built-in.



I think you're possibly confused about what JNI is or what the discussion is about.

JNI needs binary blobs. The new FFI won't. So we will not need binary bobs when we get the new FFI.

See?


... which is why we want to use FFI instead ;-) Now you already can using JNA though. JNI still requires you to write native code and compile it for your target platform, FFI eliminates that need.

Not at all! Desktop apps require platform-specific executables and installers so this is unavoidable. But the author made it sound like a piece of cake for developers used to making JAX-RS services.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: