Does Java need a modern Java UI toolkit for desktop/web?

The problem with all these desktop UI toolkits is they have a look and feel all of their own (IMHO). You can make buttons look like Windows buttons on Windows and OSX buttons on OSX but that's only superficially cross-platform.

Different OSs have different norms, expectations and design languages.

What I'd like to see is something that abstracts as much as it can but still allows you to make something look like a native app on that platform. That would mean you'd need to do some programming for each platform but honestly I don't think there's a good way around that.

The solution isn't Electron. Way too heavyweight. Wayy too resource intensive. Way too risky by having a huge attack surface.

An additiojnal problem with Java is bundling such an app. Requiring a JRE on a target platfrom is (IMHO) a big problem. They're far from universal now. Something that compiles to a static binary. There have been efforts to create self-contained standalone packaging for Java applications. My understanding (which may be incorrect) is that all of these solutions are still somewhat suboptimal.

The effort is laudable, but ultimately futile. The world has moved on from Java on the client. It is now largely relegated to a backend language for enterprise applications. Nobody really wants the heavyweight mess that is the JRE on the desktop when other frameworks do a better job. There was a case for Java-based desktop apps in the 1990s/2000s when browsers were slow, desktop UI toolkits were generally terrible and lacked cross-platform capabilities. But this was then and now is now.

So no, a new UI toolkit is not going to revive Java in the mainstream.

I’ve been a C# developer for a decade, before that I worked with Java. These days I mostly work with Typescript as we use it both for our client programming and for our backend which increasingly consists of Node micro-services running as Azure functions. If you had told me that I would be writing backends in JavaScript five years from now back in 2017. I would have likely considered you to be crazy. Yet here we are.

Before I worry you too much let me tell you that I’m not at all religious about programming languages. It’s just that using the same language for the front and back end is very convenient, and now that Typescript (and Node) are actually good enough, also possible. Which leads me to the point I want to make here. Over the years both C# and Java have also gotten much, much, better. But because programming languages and environments in general, have become much, much better, there is rarely a reason to chose a technology based on its tech-specs. Heresy to most people, I know, I know, but we aren’t Netflix. Our most expensive resource isn’t how much iron we burn in Azure, it’s our developers and the speed at which they can deliver reliable and safe applications.

I think it will become increasingly hard to “bring developers back” in this world. Because why would we come back? .Net has seen some really awesome innovation in recent years, and is still seeing it, and yet we’ve moved away from C# and onto Typescript (still benefiting from a lot of .net stuff in azure functions), and .Net moves much faster than Java. So I doubt it, but I hope someone makes it anyway.

I have been struggling with this question myself. Over the last 1.5 years, I have developed a relatively complicated Java desktop application. It is designed for use in a tugboat company. The same application is used by staff at desks on land and by crew operating out in the ocean with only occasional Internet access. A connected web app was out of the question.

It uses a local SQLite database to synchronize when it is connected to the Internet. It has a very rich mapping interface to show courses, routes, etc.

I could not stand the idea of forcing this into an Electron shell and the associated performance problems. As it is, I have a watchdog running inside the app that diagnoses any hangs of more than 100 milliseconds. (Such hangs are easy to fall into when doing GIS SQL queries.)

I don't see how I could have had any better productivity as a developer using any other software stack, but man, the GUI is very dated and out of place.

Nikita Prokopov is developing Humble UI which is worth keeping a close eye on. (Yes, it's Clojure, but Java interop is bound to emerge if it builds up a critical mass and catches on.)

https://github.com/HumbleUI/HumbleUI/

Dont be disillusioned by the negative comments. There are a LOT of Java developers as you already know. I am sure there is a percentage of them who do not want to learn another language to build/prototype UIs. Your work definitely have an audience.

Btw the demos are really good.

Great work Jeff! Java client development doesn't have to be rescued and I know plenty of Java shops that are doing fine. Also, ignore negative comments here.

A couple of suggestions:

- License. Yes, I'm aware that this library is paying your bills, but GNU license is something easy to skip. Start with Apache license. If we need comparable UI in a browser with a more liberal license, we can go with Vaadin 8 or RAP.

- How does it work with GraalVM? This is hot stuff now and you can ship your programs without JDK/JRE dependency.

- If SnapKit desktop app can be easily put on the web (and vice versa), that will be a huge selling point. Eclipse tried this with SWT/RAP combo.

- Currently, web apps are not mobile-friendly. However, this is a must these days. Not sure how hard to add support for it, but with (additional) js/css, you can do wonders.

- Javadoc documentation should be online and SnapKit should be accessible through maven. Something very common for Java projects.

- Scala/kotlin/clojure demos should be nearby. Yes, I know it is easy to translate Java samples to e.g., Kotlin code, but if google search shows "Kotlin with SnapKit UI toolkit", you'll get some attention.

- Maybe unrelated to UI library, as some pointed out, the website needs rework.

Wow. This looks like something definitely worth investigating. TeaVM seems to be the secret weapon here (HN discussion from 2021 at https://news.ycombinator.com/item?id=25978053)

What limitations have frustrated you the most in working on this?

Our company sells HW and SW for the dental sector.

Our desktop scanners for dental labs and our intra-oral scanners for dentists generate 3D meshes of the patients oral situation. The UI of the intra-oral scanner is done with javaFX tool kit/libs. A little impression:

https://www.youtube.com/watch?v=AA4IWd3Svm0

Those meshes are the input data for the CAD/CAM Software my team builds. It is a desktop app for the digital design of dental restorations. The GUI is in javaFX and 3D visualization is done with OpenGL 4.5.

Once the restorative Design is done, that app can generate many different output formats. Labs will feed the design files their local milling machine or 3D printer. Dentists can send it to centralized milling facilities of their choice to produce the crown or bridge or what have you.

Some impressions of the CAD can be seen here:

https://youtu.be/5THQMr5SAH0

GitHub: https://github.com/reportmill/SnapKit

Demos: https://www.reportmill.com/snaptea/

I have been impressed with SnapKit since first learning of it.

The discipline and effort required to build the proper framework-level abstractions to be portable to future UI toolkits is extremely impressive.

And unlike some other projects, most of the demos are non-trivial, substantial apps. Even Swing doesn't have demos like these.

Congrats, Jeff!

I thought this demo was very impressive: https://www.reportmill.com/snaptea/RM16/rm16.html

JetBrains "developed a new UI framework" for their new Editor Fleet: https://github.com/JetBrains/compose-jb

I've put a part of the sentence in quotes because actually they've written a new desktop backend based on skia for the already existing Android Compose UI API.

I think JavaFX does a good Job. However, there is always room for a better framework for cross platform UI..

JavaFX is your answer. Download the latest JDK, use Gradle or Maven as your build tool, make sure you properly use modules and you're golden. No need to ship JREs (that concept doesn't exist any more). Furthermore, you can create .exe and .app and move on.

It's kinda lame that creating a desktop app has never been easier, yet everything has moved to the cloud.

So I'm a mostly-front-end web developer and I've never used Java. This looks cool; I have a couple questions:

  - How is this running without a java runtime? WASM I assume?
  - Given the performance and accessibility of modern html/css, what's the impetus behind something like this?

Surprised there are no mentions of SWT in this thread. Isn't it still in use for Eclipse and others?

I don't believe you need to go full Eclipse/RCP/OSGi to use it.

This looks like a good toolkit for line of business apps. Being able to plug in an app into a browser would be a time saver.

It looks like you're using JavaFX for ReportMill, which is plenty modern enough in terms of capabilities and API.

Web or not web probably won't have a particularly big impact on your apps. Given that they're developer tools and those are normally client side apps anyway, it doesn't seem likely that this is the determining factor in whether or not to use them.

Revamping your website would likely be a better use of time! It looks like you made it in 1998 and haven't updated it since, for example, it only fills one quarter of the screen on my display. The screenshots are tiny and low res. The app itself is using the slightly dated default JavaFX theme - why not just spend some time on your JavaFX CSS, website and examples, and give them a fresh lick of paint?

The non-web frontend is largely dead outside of specific use cases (gaming, for example). So embrace it.

Java does a fine job on the backend. It honestly shines there. So let it do that. And let the modern front end platform (the web) do what it's good at.

I'd like it if there was a GUI theme to make existing apps not look terrible.

Jeff, how did you get them to run in the browser on a single click? I would've thought the JRE needed permission or something? It's been a while since I've run an applet. Is this sandboxed somehow?

I much prefer the Swing approach of having one solid framework, instead of a bi-quarterly new-and-shiny UI framework that goes straight from alpha to deprecated without ever really reaching production quality

This is very impressive! I haven't done ui code in a while but I would have loved to have the integrated "devtools" helpers!

I think Java could profit from an integrated client/server framework like Microsoft's Blazor for .NET. https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=as...

What’s the accessibility story here? I haven’t tried to run these locally but the web translation is completely broken given that it’s a plain canvas that doesn’t try to implement an accessibility tree.

If it doesn’t have that at a minimum then it’s basically a non-starter for business use.

Is there any stats on the numbers of people who use desktop applications outside of office tools, video editing, image processing, and basic utils?

My gut reaction is, a language investing in this space isn't all that cost effective.

Let Java die a slow corporate death and assume the role of COBOL.

They already have, JavaFX, there is a kotlin first framework:

https://github.com/edvin/tornadofx

I guess I would start with: did Java fail as a client application because of the UI? or was it something else? (I don't know the answer nor do I have an educated opinion).

I know the Swing is not under development anymore, but what did you mean by 'JavaFX missed the boat'.

From this thread it appears people are happy with JavaFX.

Isn't it pretty much Android? Already runs on Chromebooks and Windows with unofficial hacks for other platforms, including browsers.

The README page is amazing. I don’t care much about client-side Java and learned a lot about it from just the README page.

TeaVM looks amazing as well.

I used Vaadin (vaadin.com) for some web ui back in the days. You can always bundle it somehow into an electron app...

How does one develop with Snapkit? Do you have a workflow example.

Java has needed that since day one of it's release

yes. flutter has a nice approach and feels like it has a viable future. javafx seemed to fill that spot - not sure what happened to it.

Isn't that what JavaFX was supposed to be?

Define 'modern'. JavaFX is/was it. What is specifically wrong with JavaFX - what is so fundamentally different in what you think is neccessary (e.g. SnapKit) that JavaFX doesn't deliver and cannot deliver without completely redefining what JavaFX is and how it works?

A few things come to mind:

-- "Native" --

Nobody, _nobody_ has properly solved this problem. Not even flutter and the like. Native is incredibly complicated. Many frameworks tend to 'zoom in' on the notion of having everything 'look' native, but this is in many ways heading in precisely the wrong direction: Of all frameworks that intend to be platform agnostic, the _only_ one that has seen significant success is the web, which is explicitly not _at all_ native. I'm not saying that 'you should just write desktop apps using web frameworks' - I'm just observing that the push towards platform agnostic native-looking apps has not worked at all.

The point is: _IF_ it's not a web app, you most likely want to integrate into the OS a little more than a web app would: You want to interact with webcams, the file system, integrate into context menus, affect other apps on the system (e.g. accessibility tools), register itself as a 'target' for share menus and the like, and so on.

Such notions are usually quite different between OS platforms, thus trying to provide a unified API _requires_ massively distancing yourself from the 'local' APIs (you have to: Those local APIs are completely different between platforms), and this in turn increases friction to use the best / latest takes. If apple releases a new sharing sheet API, then the makers of flutter or this hypothetical 'modern, native UI toolkit' for java need to figure out how to integrate this stuff into their APIs, deliver on that, test it, and release it. This takes a long time, hence - if you want to write the best iPhone app you can think of, you're probably best off writing it in the same technologies apple itself (the platform owner) would use. So, swift or ObjC, using XCode as editor, developing it all on MacOS.

-- "Modern" --

Whatever API style you think is modern, I'm just not seeing how JavaFX is outdated relative to it. If you specifically do not like what programming in JavaFX feels like, that sounds more like a style debate. The Swing and AWT APIs are severely outdated in objective ways, but JavaFX just isn't. JavaFX is an abject failure, at least if you look at uptake (which majorly used app is written in JavaFX today?) - before bashing your head into the same wall all over again, what did JavaFX do wrong? If there's no satisfactory answer to that question, it seems daft to try again. You'll just fail again in the same ways.

-- "Web based" --

Java has tons of web frameworks already, and there are boatloads of successful websites (in the sense that a lot of money is earned with them and/or eyeballs look at them). Most of them use 'server language agnostic' UI toolkits, i.e. those written in javascript+CSS, where the java server code just serves up JSON.

If you feel that a fundamental disconnect between front and backend is in fact a bad thing and orders-of-magnitude improvement are available if you integrate these, well, there are various frameworks that do just that. They are not as popular as e.g. AngularJS+java backend, so the same question comes up here too: What, specifically, is so wrong with these integrated frameworks?

-- "Deployment" --

Perhaps the right answer is that you write a web app as normal but give tools to deploy it _as_ a desktop app. i.e. the Electron route. But you can do that today fairly easily. The problem there seems to be that these apps never quite feel properly native, and electron is a resource hog.

No matter which way I turn to try to interpret what you're asking for, I end up with: "Sounds like a bad idea" or "the problem isn't technical, so delivering a new framework could not possibly solve it".

No. Modern UI is crap.

I call it Flutter!

> could it rescue Java Client development?

No because the industry is slowly moving away from the long fashionably hated language.

Tech centric people love to complain about Electron being bloated, the same way they do about anything that doesn't run on their 4gb memory Linux hobby machine.

In the actual non HN user world, on modern desktops, average users don't really care about these things unless they notice them. Electron will keep getting by, as it should because browser based development is the future.

JavaFX is not bad at all but changes in licensing haven't helped its cause at all.

It's close to malpractice, however, to develop desktop applications at all in 2022. That is, you can write a web application, upload it to your server and you deployed a web application.

If you write a desktop application that's just the beginning because now you have to do the installer engineering, possibly deal with cross-platform problems, possibly deal with different versions of the same platform, etc.

Another thing we forget is that web browsers are on an entirely different level than other GUI applications because a web browser is designed to stay responsive to the user when loading multiple streams of data over a slow network. Contrast that to desktop applications where the "beachball" or whited-out windows is normal and unavoidable. Browsers are still written in C++ by the most advanced software development organizations because you just can't manage that in a managed language.

If you develop for a browser or a browser-based environment like electron you can take advantage of all that work... Even if it means using a maddening async I/O model.

I too was disgusted with electron's "bloat" but when I went looking for a cross-platform GUI framework I looked at gtk, tk, qt and many others and compared to electron it was like going from 1850s technology to 2050.