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.
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).
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 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
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 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.
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.
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.
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.
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.
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.
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.
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?).
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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?).
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.
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.
> 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.
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.
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.
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.)
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?
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.
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
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.
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.
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 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.
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.
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 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.
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!)
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.
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..
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.
Ok, so this starts off as “Graphics for the JVM” which sounded promising, but then the first line starts talking about desktop apps and warning bells start going off. If you read the post, it’s totally fine…if you are trying to do fast drawing or something. But no, we’re making desktop apps, with circles and triangles and squares. This just isn’t how it works, and the reason is the same as it always has been: a drawing toolkit is not a GUI toolkit.
If you want people to make good apps, you need to give them buttons and checkboxes and text fields. If you don’t, we’ll, they’re going to do it wrong. Time and time again people have tried doing this and the best we’ve gotten out of it are game UIs and Flutter, which are a solid “mediocre” in the UI department. The former probably gets a pass because it’s allowed to be quirky, but the latter is literally run by a megacorp and it’s still struggling to get basic things right.
Heck, even Swing and HTML are better than this; at least they give you components that someone actually spent time on implementing and making half-decent. Maybe they suck, but they suck together in a consistent way that is at least partially battle-tested, a must for any GUI toolkit. They’ve gotten to the point where they’re no longer just a middle finger to people with accessibility needs.
Look, I don’t want to rain in this author’s work. If you’re going to treat it as an accelerated Graphics2D, go right ahead, this seems like it would be an excellent solution for you. JVM bindings to Skia seem awesome. Just don’t, like, draw something that looks like a GUI in it.
(I could go longer about the characterization of mobile apps as constantly being purged from RAM and losing your work and IntelliJ being a good Java UI, but that would probably make this divisive comment longer than it already is.)
I think you misinterpreted what the author aims to do. He states in the beginning that the main reason for why we don't have a good UI toolkit on the JVM is because every existing solution is bringing its own drawing library and with it their very own limitations. He advocates for a drawing library that will be supported community-wide, something like Spring is.
React Hooks, SwiftUI and Flutter are modern choices that popularized the declarative approach and the author expresses its frustration that until now there was no interest in developing one for the JVM, which has all the pluses that it needs to create an ecosystem around one. Java, Kotlin, Scala and Clojure will all benefit from it. I think he is right, there is no modern graphics API on the JVM right now to do an UI toolkit or 2D/3D visualisations.
"The road to high-quality UI on JVM is a long one. We’ll need:
a graphics library,
a window/OS integration library,
a UI toolkit.
Today I am happy to announce the first part of this epic quest: the graphics library"
Maybe you misread a bit? I do not see him suggesting, to use his first step for the UI. The idea is to build the UI kit on top of it.
I get that, it’s just that this is being presented as something that will kill Swing and Electron, which obviously makes it so that many will take away “I should use this to draw my buttons” from it. I’m advocating caution before throwing away Swing right now.
Well, his intention is to create something that will eventually kill Swing (and Electron), so he probably got carried away wih his words a bit, but I do not see him missrepresenting.
This is a blog post, not a product launch. It's intended to be a foundation on which a "real" GUI library can be written. The author mentions that it is one of several steps that should allow the Java community to coalesce around a better toolkit in the long term.
I think it's confusingly worded b/c they compare to Swing and JavaFX in the first lines - so it sounds like this is aiming to replaces those. But in-effect this is just a first step towards that larger goal. Why the graphics library needs to be rewritten from scratch and they couldn't implement a better UI toolkit on top of what already exists is left unanswered - and that's confusing. All it says is "Java UI progress was blocked by the poor-performing Graphics2D"
This post is only about the Skia JVM bindings and that is indeed only the graphics layer. What you are looking for is Jetbrains Compose which is built on top of these bindings and provides the GUI toolkit.
The particular issue I have is that when you look at a library like this, and especially how it’s being sold, we’re just going to have people go “Wait, I can just draw my own UI toolkit! This is easy!” and they’ll end up with something worse than Swing because they don’t realize the work that went into Swing even though I’ll be the first to admit it’s not the best. So I guess what I hope this becomes is that a group of people who actually understand desktop UI come together and take this to make a good toolkit, and I’m trying to caution people who want to just dive in without fully understanding what this would offer them. An analogy might be a blog post announcing LLVM IR, and I advising caution against just going and writing your homebrew language against it and then shipping your software on that. This is just a part of a good UI toolkit, and I think the blog post is looking too far into the future.
Sorry if I got the wrong impression. It’s an easy impression to make when you keep complaining in multiple comments that the article is omitting key things that are actually discussed in the article.
Perhaps it’s just the way you were communicating your opinion that is misleading. It’s not just me, I can see at least three or four people here who are trying to point out things in the article that you seem to have missed.
I will concede that my original comment was unclear; I am not particularly annoyed I had to clarify it a few times. I was just (somewhat unreasonably) annoyed that poeple thought I hadn't read the article.
> Ok, so claiming I didn’t read the article is actually against the guidelines, and you’ve done so twice so I’m not particularly in the mood to really entertain it anymore.
First off, you are responding to two different posters. Second, neither vbsteven nor jb1991 said you didn't read the article, they pointed out things that were addressed in the article. The phrasing they used is explicitly called out as acceptable in the guidelines:
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
No, I am responding only to 'jb1991; here is the other comment you missed: https://news.ycombinator.com/item?id=25122691. I was annoyed because the sum total of those seemed to be a claim that I did not read it, not just a straight quote (which I had a few of already, mind you).
No, I read the post, the author mentions that this isn’t a GUI toolkit. But the reason I made the comment is that like 90% of the post is “we need desktop apps and Swing sucks and let’s not use Electron” so I think regardless of what it says in the middle it really seems like it’s selling “use this to make your desktop app” rather than “this is a general-purpose graphics library”.
I know Compose exists, and it’s exactly the concern I have: look at the example apps, and compare them with true native desktop apps. Can you really call the result a good desktop UI? Is it not just a mobile UI that was blown up? Actually, it’s difficult to even call it a good mobile UI, because at the moment it certainly falls on the side of “bunch of shapes put together” rather than “UI toolkit”. Of course, while UI is just a bunch of shapes on the screen, it needs to be cohesive, and familiar, and accessible; not to mention the many, many behaviors under-the-hood that don’t show up in a screenshot.
> I know Compose exists, and it’s exactly the concern I have: look at the example apps, and compare them with true native desktop apps. Can you really call the result a good desktop UI? Is it not just a mobile UI that was blown up?
Because the project is in alpha? And it says so on the page?
To quote from the article on skia:
--- start quote ---
We are so used to things we can hack together in a week, nobody is thinking in terms of years. And good UI requires years of work. It’s a big commitment.
The road to high-quality UI on JVM is a long one. We’ll need:
The author of the blog post works for JetBrains (I think). JetBrains are interested in moving away from Swing for their product line. Their intended replacement is a port of JetPack Compose to the desktop, perhaps because it's a Kotlin-centric framework and Kotlin is their baby, perhaps because Google is funding Compose and they hope that it'll have more money invested in it than Swing/JavaFX did.
Compose renders with the Skia graphics library. Hence, Skija and Skiko, bindings to Java and Kotlin respectively. And hence their Compose for Desktop effort.
The grandparent comment is questioning whether a mobile toolkit ported to desktop is really going to become competitive with Swing anytime soon, given that although Swing is admittedly by now a very old API, it's been continuously developed for 20+ years and is thus by now one of the most battle tested and matured frameworks in the world.
Now you might ask, but aren't Skia bindings useful in and of themselves? Well sure, maybe, but bear in mind Java has had a Skia equivalent for a very long time via Java2D as used in Swing, and JavaFX also has a Skia-type subsystem where you can issue drawing commands and they get hardware accelerated. So to understand the value of this new library you very much need to be able to do an in depth comparison of Skia vs Java2D vs the JavaFX Graphics subsystem. Very, very few people have the expertise to do this and the blog post doesn't really try.
I've actually looked at this topic in the past few months for various obscure reasons. I'll say that:
• Skia is the core of Chrome so it's actively maintained, which is good. On the other hand so is Java 2D.
• Skia seems to have some support for playing animations exported by a visual animation builder called Lottie, which is nice. Java 2D doesn't have that.
• You can partly embed Skia in a web page via WebAssembly, which I guess is neat. You can embed Java2D in a web page via stuff like TeaVM too though.
• There are no benchmarks comparing these libraries, as least not as far as I know.
• They are both hardware accelerated via OpenGL / Direct3D. Skia also has experimental support for Vulkan.
• Skia is a C++ lib that therefore requires manual bindings to other languages. Java2D/JFX are JVM APIs that can be automatically bound to a wide variety of languages, e.g. JavaScript, Python, Ruby, etc.
• Skia's documentation is rubbish. Check out this excuse for a website: https://skia.org/ - a 2D graphics lib is a complex thing. Where are the docs? E.g. click on the main API objects and you get a handful of semi-random examples with one line of explanation for each.
Basically, Skia is a component of Chrome that happens to have its own website. There is some vague attempt to make it into a real, production quality API but when internal docs for Skia developers drastically outnumber API docs for users, you know what you're dealing with. Java2D and JavaFX are designed to be APIs consumed by lots of developers, in a large variety of languages.
Sounds like in principle, Skija is an attempt to take the benefits of Skia and bring the shortcomings (for this use case) up to par. What's taken for granted is 1. Skia is better/more/performant/nicer than javaland status quo, and 2. Jetbrains has the resources/experience to "hand-craft" a nice Java API over it. And then on to all the other steps.
> So to understand the value of this new library you very much need to be able to do an in depth comparison of Skia vs Java2D vs the JavaFX Graphics subsystem. Very, very few people have the expertise to do this and the blog post doesn't really try.
This is the main point, which I can only assume JB have answered internally. They are probably the biggest Java GUI shop in terms of users and revenue (at least that I know of), so I'm not too too skeptical when one of their developers with some clout says "AWT, Swing, and JavaFX came with a lot of quality and performance drawbacks"
Eh, maybe. Familiarity breeds contempt. I think they feel like they're sort of out on their own with Swing and the cool kids are moving on to new things. They like the DSL aspect of Compose. Could the advantages of Compose be brought to Swing - probably. My guess is yes. But if Google are planning to spend the next decade heavily investing in a Kotlin-first toolkit and millions of Android devs will learn it, you can see how they arrived at the decision to go the whole way.
AWT actually uses native widgets, so if your needs are simple it's one of the fastest ways to go as the code is all loaded in memory already and written in C/C++, it's a part of the OS after all. Modern Swing isn't slow. IntelliJ's performance isn't limited by Swing I think, it's much more limited by RAM in general.
JavaFX never reached the maturity of Swing in terms of raw stability, but it's got a drastically better API and TornadoFX shows you can layer a Kotlin DSL on top very easily. Frankly I wish they were investing in JavaFX instead because it's actually a desktop toolkit, and is already "there", whereas Compose is going to be beta-ware for a long time. JavaFX has been stabilising over time because for the last 7 years or so it's not been adding many features, the work has all been bug fixing and performance improvements. It's a mature toolkit that just didn't quite get critical mass.
I assure you that I’ve read the whole thing, and since I’ve already answered this question a couple times in this thread, I’ll direct you to my responses there.
The author is exhibiting heavy denialism. The first indicator was gesturing towards IntelliJ IDEA as an example of a good desktop app. And whaddaya know, it turns out the author is affiliated. This isn't to say there's any intentional deception here—it's somewhere between self-deception and simply being unaware of one's own blindspots.
Without going through the effort of installing and running it, it's easy to see that IDEA looks just as good as it did 5 years ago—which is to say not great. And without any evidence saying otherwise, it's reasonable to assume that it hasn't gotten any more lightweight or nimble since then, either.
People writing JVM apps who tout their quality never seem to understand that their firsthand experience does not translate to other machine/system configurations that other people are running. It very well may be the case that those apps look and feel worse than an Electron app. (And one doesn't have to be a fan of Electron apps to admit this.)
It has actually. It starts a lot faster, and has a "lite" mode where it's more like a text editor.
As for how it looks, well, it's an IDE. It looks fine to me. There's a dark mode if you want it, the look is modern yet dense: sparsity being a common issue with web apps. Plenty of people use and like it.
The point about information density cannot be stressed enough for a "pro" tool.
Its keyboard friendliness is also highly underrated due to being a GUI -- I found it's rivaled only by emacs/vim in that I can go an entire work day without clicking around with a mouse.
It has nothing to do with dark mode. Dark mode screenshots are the first thing you'll see when you go looking for how IDEA looks today. It looks like a dark version of the UI from 5 years ago, unsurprisingly. Which means it still looks about as out of place as any Electron app. Although one would hope they've dealt with the bad antialiasing by now. Hard to say without downloading and running it, but the continued lack of polish and past propensity to pass the buck makes one question, "why bother?"
> As for how it looks, well, it's an IDE.
Not sure what this is supposed to mean. There are good looking IDEs. There's not something inherent to them that makes one look the way IDEA looks. It's the aforementioned blindspots and the "I don't see anything wrong with it" attitude that causes that.
My point is, I don't see the problems. Anti-aliasing works fine. The text looks good to me, always did. Looking out of place ... well, on macOS at least you can pick a mac-like theme. I don't because I prefer the IntelliJ theme but there's not much difference to it. All Mac apps are Windows 98 style battleship grey these days, the era when native toolkits had radically different looks to portable toolkits is over for a long time now.
> 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”.
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.
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.
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 ?
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.
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 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
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.
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?)
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.
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, ...)
> 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.
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.
> 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).
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.
> 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.
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)
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.
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.
> 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.
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 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]
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.
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 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.
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.
... 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.
Java had the issue that it was hard to build a consumer desktop app, because Swing etc. were a bit removed from native (L&F, behavior etc.). Those didn't matter as much for desktop apps, which always looked gross. (The issue that they were less usable than the terminal apps they sometimes replaced is another issue)
These days, I'm not sure if fixing that is enough. I long for the days when minor UI inconveniences like Borland-ish button icons or that weird Basic thing in the early days of OS X were the worst offenders. Quite often it's _required_ that you deviate from your platform quite a lot, as we've embraced form over function with mobile- and web-like "experiences". Whitespace everywhere, mystery meat navigation and non-conformant widgets and shortcuts that make you long for the skeuomorphic mistakes of the late 90s. Neither Apple nor Microsoft seem to be too much into HIGs these days, and Linux never was.
So if this delivers the bricks, what kind of houses would we build with it?
"Those didn't matter as much for desktop apps, which always looked gross."
I don't understand what you mean by this. I don't think desktop apps "look gross" at all. Or did you mean that Swing desktop apps looked gross because they didn't conform to the native look and feel of the platform they were running on?
I really liked Processing [1] It's possible to create practically every thinkable visualization from scratch with surprisingly little design knowledge/programming effort. Not only is it far more intuitive and flexible than d3.js but also it can be directly called as Java program. Apparently the Arduino UI is a fork of its editor. FWIW it's hard to tell that the Arduino IDE is not a native app.
I used SWT to create desktop UI prototypes. The biggest issue of SWT is the distribution channel: to use the usual Maven repo you need a non-official package (this was around 2017). But other than that is a decent UI lib: it uses native widgets, it supports HiDPI, the layout using attachments are easier than Swing.
I wonder why SWT is not popular in the JVM (my guess is the decision to distribute it using Eclipse p2 by default, and the lack of visibility outside Eclipse)
They finally have official[1] Maven packages[2] now! I have no idea what the version numbers are supposed to mean though. Or what's a good way to choose the correct platform-specific JAR in your build.
I've been building a map editor using Kha [1] and Haxe UI [2]. Kha does cross platform, hardware accelerated graphics like Skija (it abstracts OpenGL, Metal, and Vulkan). Haxe UI adds a DOM, standard components, CSS styling, etc. I've found it good (the small Haxe community makes author interaction brilliant), though not perfect. Great for the number of people behind it.
Using Haxe, the apps can be compiled for native or run in JS. That probably lands it in about the performance category of JVM or above, not that performance is the key factor here.
I worked awhile ago on Haxe UI's text field emulation, and there are many tiny details that are easily missed. Line wrapping, text selection, keyboard controls (Home and End), everything. I think those details being spot on are as important as UI styling for most real users.
I am a web developer and I'm only used to developing in JavaScript and a complete beginner in Java.
I had an idea for a desktop app and wanted to try out something in javafx as that's what google pointed me to.
The build setup for java projects seems to be incredibly complex and I don't find any sort beginner friendly tutorials related to javafx that work on windows without any issues.
Then I looked at Android development setup and it's even more insane in size and complexity.
I think if the entry into java app development was as easier as electron it would be amazing! I get that it's a well mature platform with a massive ecosystem but it needs to be have something like npm or yarn for javascript development.
And importantly are there any thin and light JVMs that can be bundled with this? I'm thinking AdoptOpenJDK openJ9. It seems to be well suited for this use case. would it be efficient in the RAM and CPU usage? If not I'm not sure why this would be any good since we can develop stuff much faster with electron at the moment.
When one wants to implement a new desktop UI framework there is an elephant in the room - the rich text editor. You can implement your own layout engine, styling, fonts rendering but production quality feature-rich text editor is another level of complexity.
Errr, is there some example I can compile both into a Desktop app as well as Android app easily? I never got why we never got convergent Java apps that run everywhere... It's seemingly almost easier to do that with Qt than with Java
If I could get an example written in Clojure that'd be even cooler :)
We're currently in an era where UI mostly means doing react type stuff or IOS/Android native, for whatever very loose definition of native you wish to use.
A trend that is interesting here is jetpack compose and swift UI, which are both inspired by react but better in the sense that they make full use of their respective type systems to make things like data bindings a lot less painful than they are in react. At least that being painful must be a reason why they keep changing how that works in every major release.
Add internal DSLs to the mix and you are basically looking at a nicer way to do UIs. That's only covering mobile currently unfortunately. However, Jetbrains just announced Compose Desktop which brings this to the desktop as well. If they figure out how to target web and IOS with this, they could very well have a winner.
For the web there is currently something called Fritz2, which runs via kotlin-js and basically adds very similar style bindings to a react like component framework. It's fully written in Kotlin and I've been meaning to give it a try so I can use my multi platform kotlin libraries there as well without having to figure out react and how to make that play nice with things like co-routines, data classes, etc.
For me the trend here is new UI frameworks originating outside of the javascript world gaining traction and eventually ending up running in a browser as well. IMHO it's that that is ripe for disruption.
I watched an interview recently, between an Android developer and an iOS developer. One was asking:
“Does someone still writes desktop apps?”
To which the other answered:
“I have no idea… Maybe?”
Both of them were recording it on a desktop, in a desktop application, while having a call over another desktop application. Multiple other desktop apps were probably used for post-production. None of those were written by magic elves or left to us by a mighty ancient civilization. The desktop might be less trendy, but only because it’s harder to sell useless crap here.
-----------
"react type stuff" and iOS/Android do not cover this, but you probably knew that.
I've not encountered a single desktop application project in the last 15 years in this industry. Very different from my first 10 years when I was even involved in that kind of thing a couple of times. I'm on Linkedin. Recruiters seem to have a fine talent to ask me for just about anything involving software spanning the entire spectrum of frontend, backend, embedded. Most of it is for stuff I don't even have on my CV. Based on that, I don't think I've seen even a single request for anything desktop based in the last ten years. Plenty of react and other web based stuff. Plenty of Android, IOS, and even Symbian when that was still a thing. Lots of backend in all flavors (even got a haskell one the other day). But not things like Swing, JavaFX, etc. That just doesn't happen. Not even rarely.
I'm sure there's a parallel world where enterprises still run JVMs on ancient windows XP boxes that are no longer supported where they feel compelled to commission new applications. Just haven't come across any such project. It's not just less trendy from my point of view but dead as a doornail. Not a thing anymore that people actively recruit for. What little UI I come across on my own desktop tends to be either web based (electron) or native (I'm on a mac so mostly objectiveC and swift these days).
At this point, desktop apps are not the domain of enterprise. They tend to be consumer focused, particularly for creatives (video, audio, graphics, etc. etc.). Most of the development for these apps takes place in smaller contexts (not necessarily startups). It also tends to require skills that most programmers these days don't have in abundance (largely because of the industry structure that you describe above).
But none of that will involve Swing or JavaFX etc., because these are just not performant enough for the type of apps that are still required to remain native/desktop.
I run a mid-size highly complex native/desktop FLOSS project, and it is just jaw-dropping for me to encounter people who say they have 5-16 years experience as a software developer but cannot consider compiling software. This happens regularly in the context of our project.
Patience, I think. 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."
That's quite an observation, thinking of the hundred thousands of man-hours probably spent on both Swing and JavaFX and SWT, and they power a huge lot of high-quality, highly polished applications, including real-time graphics.
I'm sure this work is great, but no need to put the competition down...
I love the night mode setting on the top right of this site. Totally useless, but amazing lol. It feels like I'm reading the site in the dark with a flashlight.
The picture I'm seeing is that it would seem that they're in the same ballpark, and v8 may even be a smidge faster, for general purpose business object flogging type stuff, but Java is significantly faster for straight-up number crunching. The one where there's the starkest difference, k-nucleotide, Java gets to take advantage of a fastutil collection. I don't think an equivalent to that hash map could be built in JavaScript.
Those benchmarks don't cover this, but I wouldn't be at all surprised to discover that Electron can does actual UI drawing more efficiently than Java can. In Electron, that whole layer is a bunch of (presumably) carefully optimized C++ code, while in Java the bulk of it's still going to either be managed code, or be taking a lot of marshalling hits if it's calling into OS APIs.
Long story short, it would appear that, based on those benchmarks (which, we all realize benchmarks are a lie, but still) the only spot Java clearly beats JavaScript is in applications where someone who cares all that much about performance would choose neither Java nor JavaScript, anyway.
Also, when you look at UI benchmarks for web frameworks replacing/updating thousands of DOM elements per second, I have serious doubts the problem of web-based UIs is performance.
I agree Electron is a cancer, but not because it uses web-based UIs, but because every app ships its own version of Node + V8.
A couple of years ago I built a cross platform app using the native web view on each platform (WKWebview on macOS/iOS, WebView on UWP, Chrome web view on Android and ChromeOS). The app for macOS was like a 4MB download from the Mac App Store and it consumed like 15-20MB or RAM.
> Long story short, it would appear that, based on those benchmarks (which, we all realize benchmarks are a lie, but still) the only spot Java clearly beats JavaScript is in applications where someone who cares all that much about performance would choose neither Java nor JavaScript, anyway.
The performance of a non-memory-safe language is usually 0; if you don't care about the time to get a correct result rather than just any "result" then why would you use a programming language at all?
Especially in a world where C is still the most popular language in domains such as spacecraft control software or operating system kernels where correctness is of the most paramount importance. One doesn't need to meditate on that for very long to realize that choosing a non-memory-safe language is not a decision that correctness is not important, it's simply a decision that the programmer must be personally responsible for yet another aspect of correctness.
Also, needing to make a hard choice between "faster than Java" and "memory safe" was a problem for the late 1990s. 20 years later, we have a lot more options.
I've spent a significant proportion of my career working on financial codebases that did serious number crunching in Java and were performance-bounded, and Java was still absolutely the correct choice for those codebases. So the idea that performance is irrelevant for those domains in cases where Java is a reasonable choice is completely wrong.
Having the programmer be personally responsible for memory safety doesn't work, we know that now. What spacecraft control software is written in isn't really C any more than typescript is javascript: yes, the final runtime artifact is in C, but the "source code" includes a lot of additional verification material without which it wouldn't be valid. As for operating system kernels, even Linux isn't written in C any more because C is too unsafe; rather it's written in an ad-hoc language that provides stronger safety guarantees (which it compiles by passing special parameters like -fno-delete-null-pointer-checks to GCC).
The idea of improving runtime speed and benchmarking has really bifurcated into single threaded and parallel programming universes. Most platforms have O(10) cores now so it's an order of magnitude question, but exploiting that is a problem that few languages are helpful at. JVM is much better for that than JSVM though.
(But usually the much bigger speed problem is in the programming phase, better to optimize for programmer performance than runtime performance or risk not delivering anything due to time/money limitations)
The main reason (JVM apps are not more popular) is that the average JVM desktop app does not perform better (or use less resources) than the average Electron app. I know this is not supposed to be that way, but one way or the other, it is.
On top of this the web UI developer community is orders of magnitude larger.
I don't think that's really true. Years ago, I maintained a Java desktop application, using SWT as the graphics library (not even mentioned by the post author which is weird.) It wasn't a big application, but also not stupidly trivial. It would start fast, run fast, and didn't need much RAM at all.
There are of course examples of slow, heavy java applications, but I don't think it has to be that way. I'm not totally sure what I did differently aside from consider my dependencies (e.g. using a lightweight dependency injection framework rather than something like Spring), but it's definitely not a given that Java desktop applications have to use a bucketload of RAM.
I'm glad to see this and Compose arrive on desktop. It feels like a potential good middle-ground between a fully native OS toolkit, a cross-platform native toolkit, and an embedded web app. I don't think Java is inherently bad for the job, just that the previous UI toolkits were not what we needed.
I'm studying how to rewrite our online word-processor in a stack that allows us to render documents to android/iOS/desktop natively.
Skia stands out as the obvious choice as a rendering library, Our team though is essentially a JS/Java workshop and writing C++ will be shooting our own foot.
I found Skija a while back but it looks like we need JVM and the JVM story on iOS is complicated (non-existent even?)
Fluttter does a good job at abstracting away Skia and exposing Dart APIs that is truly cross platform (Web/Desktop/iOS/Android) – but Flutter will never expose low level Skia APIs because that's not their goal. The abstraction is too high to write a word-processor.
I'm yet to find a reasonably iOS friendly abstraction over Skia that targets both iOS/Android and desktop platforms.
> Patience, I think. 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.
Lol what? After years, Apple is already on to the next user interface. All the "good UI" happens in Figma, you're just programming it, hopefully fast & without bugs, what is taking so long? And as a fellow programmer, no thanks, I would not like to spend years developing a UI that could be done in weeks.
We had an engineer that said it was going to take 3 months to add a sticky header to the site, because he needed to do it "right", using his home grown state machine library on Github with 3 stars. He was shortly let go.
There was a thread on /r/Java about Java GUIs. Seems Jetpack Compose is a potential new player that looks promising. No one seems to know if JavaFX or Swing is the recommended route.
Happy to see new developments here, though FWIW, I've mostly had a good time with JavaFX, especially in Clojure, where there's a neat Reagent-style (a React wrapper) library called cljfx[0].
It's true that Oracle has mostly divested here but I'm excited to see what teams like Gluon do with it, especially for mobile development. It's nice (though perhaps a mixed blessing) to be spoiled for choice in Clojure land, since you also have great access to the React Native ecosystem.
What are the problems with JavaFX exactly? I think it looks great but i don't have loads of experience with it, it's easily more customizable than Swing too and has a nice WYSIWYG graphical editor.
Instead of Skia bindings, probably the effort of building a C++ UI toolkit that has the features he needs and THEN do Java bindings for it would prove more useful for the community instead of tying the UI toolkit to Java. That's kind of what's missing in my opinion, something that does the hard part of UI, integration with native OS controls (eg. open dialogs, etc.), accessibility even with custom UI drawn using 2D primitives, etc. and that would be a great project that would also benefit the author as long as it has Java bindings.
ah, the old web vs java discussion. "why does the browser not come with all the components i want built-in, having the exact look n feel that my OS has?". "i have to actually write code to get a popup?". "markup language? style sheets?? bollocks!". "surely, java is more mature and will enable me to make better apps, in less time". "it's running on a JVM, didn't you know?". "so it's more performant".
ok. js css html won the web platform. and they have an increasing piece of native. oops! this is not a random trend, but for a good reason.
java for GUIs is not going to be popular again. it's already been tested and it failed the test.
the old timer java mindset still wants the web but it does not want to learn web.
working with the web is not a "hack", nor is the DOM only suitable for representing "documents". you left in 1995 and failed to catch up with modern standards. it's a flexible system, but does not come with all the batteries. but to counterweigh that it has a massive ecosystem, a package manager with plenty of off the shelf parts, if you want them. performancewise, the browser engines are getting faster and faster every day, optimised for rendering. v8 is hugely successful natively. the DOM is very suitable as a generic GUI model to work with. back in 1995 it was not.
wake up Java devs. your arguments are getting increasingly flaky..
> with a lot of quality and performance drawbacks. They were so significant that only one company managed to build a decent-looking app in Swing [Link to JetBrains].
Until I found the J-editor, I sort of agreed. I never understood why that project didn't get any traction; very well made IMO, and it looks good too.
That does not help of course. To be honest it did have a website (he has written a lisp implementation which comes with the editor as well ABCL - [Armed Bear Common Lisp]). I'm pretty sure the build instructions don't work either, and all sorts of other problems. But if you just download the binary distribution from sourceforge, and start it up (java -jar j.jar), you will hopefully see what I mean. It looks nothing like a Java desktop app. He has an excellent icon set, and he overrides the rendering of all sorts of components (scrollbars etc.) making it look superb.
In a past life I created a video game in JavaFX. Its on Steam. It was hard to do, but I really didn't know what I was doing when I started. I also do not know if JavaFX was missing any features that would be desired for video games, that maybe other libraries have. Nonetheless, for selfish reasons more libraries in this space is welcomed.
I've been using Java mostly for stuff that runs from the terminal and I always wondered why there are almost no games developed with it. I know this submission is not about games but it's related.
The very few games that run on the Java platform are very resource hungry, even more than some alternatives made in JS which is supposed to have a worse performance.
C# is better for gamedev for quite a lot of reasons, but most importantly because it has value types (structs) that aren’t boxed. In gamedev you use a lot of small-size types such as Vector3 or Vector4 for all sorts of math, but if you implement them naively in Java you have to always heap-allocate them, which brings severe penalties in terms of cache locality and GC. Modern Java gamedev libraries like JOML tries to avoid this by using NIO buffers (JVM provides some utilities to manually alloc/dealloc memory), but the API is quite finicky as a result. (Plus, there is no operator overloading in Java, which is another bummer.) Project Valhalla is trying to add proper value types to the JVM, but sadly as of today the project seems a bit abandoned... (See https://wiki.openjdk.java.net/display/valhalla/Main)
Agree, and not just gamedev, I think for desktop apps this is an issue as well. The memory profile of a Java app suffer from lots of unnecessary boxing. Also, the GCs are not designed and tuned to desktop apps, but to backend services. So they'll exhibit behavior like never releasing memory back to the OS and hording 100% memory.
As lasagnaphil mentioned, lack of value types (structs), operator overloading makes it trickier.
Also, Java doesn't have as many bindings to gamedev C libraries, so it's harder to get started, and the interop with C is harder in Java than in C#. C# has some cool features like sequential StructLayouts.
C# is actually rarely used for making game engines, but it's popular as an embedded scripting engine for games. I think C# has a better embedding story, because I've never heard of any projects embedding Java (I am sure they exist though).
Lastly, Java has a bit of a stigma for being a low performance language. While that may or may not be true, and there's been many popular games written in Java, such as Minecraft or most of the Android games, the stigma still remains and jokes about Java being slow are very popular.
First of all... WOW! This is an exciting project. Second of all, the blog is beautifully designed and has a hilarious author portrait at https://tonsky.me/projects/. He appears to be from either Florida or Okinawa, not sure which.
It seems like most graphical applications written in java and running on macOs adhere to the system's look and feel. In fact, you use good ol' Swing with the mac look and feel slapped on top. Whether or not the app behaves like a native app comes down to how it's written.
The author totally misses the real problem with jvm desktop apps, deployment. Either the jvm is bundled with the app or some other (platform dependent) hack has to be employed to ensure a correct version of jre is on the machine. Microsoft manages this nicely with .net btw.
The author is an employee of JetBrain.
I believe JetBrian is using jlink [1], a tool that let you embed the modules of the JDK you need with your application, for all their products since they have migrated to JDK 11.
It is the recommended way since Java 11 (no JRE there) - using jlink can build smaller packages and app developer doesn't depend on the JDK/JRE on the system.
Isn't Microsofts solution, starting with .NET 5, essentially the same as Java's jlink/javapackager – i.e. minify and bundle the whole runtime with the app?
> People crave for native apps. Nobody wants to work from the browser.
Some do, some quite the opposite. Me personally i want to have as few desktop apps installed as possible. They are warranted only in few special cases - browser, video & music player, Excel. Other than that there really is no need to have any desktop app nowadays.
> Both of them were recording it on a desktop, in a desktop application, while having a call over another desktop application.
Yeah this can be easily done from browser also
> it’s hard to select text, hard to search on a page, hard to have multiple tabs, hard to move data between apps
excuse me? It's harder to select text or search text in browser than in desktop apps? What? Text search is one ctrl-f away on ANY web page. Switching between tabs in a browser is alt-num.
Desktop apps have no tabs and a lot of times you switch between completely different UIs.
Moving data between apps depends completely on the app itself. It either offers some kind of data export or does not. It doesn't have to do anything with desktop apps or web apps in general
> For example, you are adding an event to the calendar. You need to lookup an address for the event in the mail, which has a link that opens a browser.
Yeah in a web apps you at least have some unique link to it. Linking to something on your local computer in some desktop app isn't even possible
> Ability to have multiple windows open at the same time is the desktop’s superpower.
You know you can have multiple tabs open in one browser right?
I like Nikita's articles and if he or anybody prefers desktop over web that's fine. Also the library he is starting - great. But the announcement could really omit the nonsensical comparisons and generalisations of web vs desktop
> > it’s hard to select text, hard to search on a page, hard to have multiple tabs, hard to move data between apps
> excuse me? It's harder to select text or search text in browser than in desktop apps? What? Text search is one ctrl-f away on ANY web page. Switching between tabs in a browser is alt-num.
That is clearly about mobile in contrast to Desktop.
But on a seconds thought - there are people who really "work" on phone? I just can't do anything serious from phone be it native app or web app. The experience is so much worse for me that it didn't even cross my mind it's about phones.
Not all the incredible, to be honest. Apple has pushed the iPad as a laptop replacement, and that was well before it got the desktop-ish features it has now.
Nope, there are lots of languages that compile to WASM. In fact, Kotlin compiles to WASM, and you get the best of both worlds, able to interop with the JVM, and compile to WASM (and C++/ObjC, and JS)
Your comment makes me think how WASM will go through this hype phase where people will think is a panacea to build things for the browser..
Hype gold rush all over again, but applications built on native or even javascript ones in the web or Electron will perform better in most cases. Of course companies will think its great for them to have only one codebase for every platform, but applications built with Javascript or Typescript for the web, with eventual WASM module here and there will be a better fit, so it will be risky to try to cut expenses and development there.
WASM will be awesome to bring great tech that is only available in native platform to the web, like FFMPEG, or to accelerate some code that uses a lot of math. But i think that people that are going way down into this WASM rabbit hole will have a wake-up call pretty soon.
WASM will open some blue-seas for sure, but they are limited to some niche scenarios and using WASM for application development for the web, desktop and mobile wont be one of them.
I don't think of WASM as web specific, I think of it as a portable compiler IR format, and from an untrusted third party code, isolation standpoint, running code in WASM has nice security properties.
This is why you see it starting to be used for "serverless" deployments.
> This is why you see it starting to be used for "serverless" deployments.
For cloud like scenarios WASM probably will be a hit, given its safer and a good target for providers to let developers to create customized apps in any language they want.
Also there's centralized decision on which tech should be used. And this make the adoption of new tech much faster.
Sure its a portable IR, but is a very limited one and therefore it will be sub-optimal in a lot of scenarios compared to the traditional native applications.
In the web alone it will be sub-optimal to the state-of-the-art optimized javascript of today in a lot of cases, even having a much better performance in some special cases. And in the case of desktops, mobile, etc, this will make it even better for javascript applications, which will profit the most in this scenario, with hybrid apps (javascript + WASM).
Of course, the FAANG that control the platforms would love to limit more and have absolute control over the platform which will probably be the only native app allowed or that people will run. But the day WASM take the world and we are not allowed to run native applications anymore except the ones the walled gardens allow us to, will be a dark future compared to the freedom we once had.
Clean-room monopolized innovation and big tech mammoth's..
Awesome initiative. I'm currently building a video game on libgdx. I wonder if I could rewrite the 2D UI using this (like, if they could be integrated at the InputProcessor and SpriteBatxh levels)
I have not used CLR but last time someone said here it was abandoned (I know, not what you said!), Alex Miller response was that it was up to date with the JVM version:
This is only incidentally correct (last stable release was June 6, 2019), because clojure is still evolving, just slowly and stably. A new prerelease was announced September 4, 2020 at https://insideclojure.org.
Some Clojure libraries have a hard dependency on Java (or JavaScript, in the case of libraries supporting ClojureScript) - Clojure does not cover all use cases. For example, if you want to do anything more complicated than find-all-matches with a regular expression you need to call the underlying Java classes from Clojure. I expect this is probably the biggest obstacle to getting Clojure on CLR working properly: the language is not the issue, the libraries are.
What kind of use cases have you had with the regexps that were not covered? (Just curious as I've not hit this). The builting regexp support can do many kinds of advanced regexp things such as having a callback fn return the substitution or precompiling into regexp objects, lazily iterating over matches etc.
Yeah, to that extent, I feel like you need to pick your runtime first with Clojure. Like you said, it dictates quite a lot about your development options.
I've found apps made with JUCE https://juce.com/ always look great and have really good responsiveness.
Now on the JVM front, I think one problem it has for desktop apps is the memory usage of the JVM is just terrible for desktop apps. It's clearly optimized for backend services assuming they are the only app running trying to squeeze all performance out. But a desktop app needs to be lean, and currently I'm not sure the JVM is tuned to those use cases, and Java is missing a few features for lightweight objects that could help as well with memory usage.
> The first reason is performance. JS is a great language for building UI, but it is much slower than JVM. Wasm can be fast but implies C++ or Rust.
> 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.”
> That means there’s a very low ceiling, performance-wise and quality-wise, of what a web app can do. I believe we can, and should, do better.
> Electron taught us two good things, though:
> People crave for native apps. Nobody wants to work from the browser. People don’t care if apps don’t look native to the platform as long as they look good.
Regarding Electron, I think we "should" start to talking about more like "Browser Apps for Desktop" instead of just "Desktop Apps" which is broad term.
PR for JetBrains? I think there are plenty of good looking JVM desktop apps which are equally or more good looking as JetBrains stuff. Electron and JVM is bad because they require a lot of resources and that occasionally JVM has security issues
Not sure why this is getting downvoted, but JVM is just as native as browser is. The jetbrains IDE mentioned in the article is especially very clunky and slow resource hog. In fact so much, that I would actually prefer using electron app over it.
Whaat, I would not call intellij unbelievably fast, but it is a resource hog because it does a million thing at once. Compare it to visual studio, which is something that barely works and has inferior auto-complete, etc.
An electron app of that complexity would require a supercomputer to even start
Thank Mozilla for Firefox reader mode. This site is horrible to look at. And because of that, dear Nikita, I haven't looked at your repository. Remember the rule "first impression matters"?
Nah, I'm good. Java and its related technologies can die for all I care. I really hate Java. I use it every day because that's where my money come from, supporting legacy crap from 90's but I really hate it.
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.