13 ms·

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

If Java had a modern UI toolkit to create & run apps natively on the desktop and in the browser, could it rescue Java Client development? I've been working on SnapKit for several years (+) to rescue my apps from obscurity by deploying in the browser and it's gone reasonably well, so I'm wondering whether it could be more: GitHub: https://github.com/reportmill/SnapKit Demos: https://www.reportmill.com/snaptea/ jeff

thedougd 5y ago
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.
teknopurge 5y ago
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.
jeffreportmill1 5y ago
GitHub: https://github.com/reportmill/SnapKit https://github.com/reportmill/SnapKit Demos: https://www.reportmill.com/snaptea/ https://www.reportmill.com/snaptea/
fillskills 5y ago
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.
gjvc 5y ago
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 https://news.ycombinator.com/item?id=25978053) What limitations have frustrated you the most in working on this?
- jeffreportmill1 5y ago
  Yes! TeaVM is an under appreciated absolute jewel! The big challenge was having to write most of a UI kit to basically abstract Swing. But there is a surprising symmetry between basic Swing+Java2D and HTML 5.
  - gjvc 5y ago
    Well, congratulations for the SnapKit project so far. I have now got my project to tinker with this weekend. :-)
deleted 5y ago
[deleted]
stuaxo 5y ago
I'd like it if there was a GUI theme to make existing apps not look terrible.
- jeffreportmill1 5y ago
  Thank you for that - that's why my promising career in graphics design went kaput. I'll hire a professional for version X. :-)
  - digisign 5y ago
    It looks just as it should look, ignore content-free criticism.
sidcool 5y ago
I think JavaFX does a good Job. However, there is always room for a better framework for cross platform UI..
simonw 5y ago
I thought this demo was very impressive: https://www.reportmill.com/snaptea/RM16/rm16.html https://www.reportmill.com/snaptea/RM16/rm16.html
- jeffreportmill1 5y ago
  Thanks! The ReportMill design app was the major driver of this.
  - qorrect 5y ago
    To me the SnapBuilder is huge, bravo.
- fillskills 5y ago
  Wow very impressive indeed
- robertlagrant 5y ago
  Wow that's awesome.
danielvaughn 5y ago
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?
- TeaVMFan 5y ago
  SnapTea leverages TeaVM https://github.com/konsoletyper/teavm https://github.com/konsoletyper/teavm to convert Java to JS. However, SnapKit provides an entire UI framework layer too, enabling app portability to other environments (like the desktop JRE).
- jeffreportmill1 5y ago
  TeaVM compiles to JS and includes the basic JRE runtime. Still very lightweight!
  - danielvaughn 5y ago
    Oh that's an interesting approach. I'm really into these kinds of projects because I'm trying to create a "design language" - a DSL built specifically for UI/UX designers. The idea is to provide them with something kinda like CSS, but using their own vocabulary and mental models. My thinking is that if they can write code describing interfaces in a way that makes sense to them, then all a developer would have to do is wire it up with behavior. No more handoff or recreating UIs from design mockups.
hankman86 5y ago
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.
- lumost 5y ago
  Aren't android UIs predominantly Java?
  - DaiPlusPlus 5y ago
    Android's "native" UI library has hard dependencies on key components of the Android OS that go far beyond what can be provided by any random Java JVM/JRE (i.e. you can't simply use Android's UI .jars almost anywhere like we can with AWT and Swing). Saying "Android's UI is Java" is like saying "Apple's macOS Cocoa is x86" - technically true, but belies the sheer volume of transitive dependencies.
    - mike_hearn 5y ago
      That's true of classic Android UI, which isn't that great anyway. The new JetPack Compose ui toolkit is cleanly abstracted from Android and works on the desktop as well.
  - datavirtue 5y ago
    Yeah, as are some of the most popular and modernized desktop apps. I'm always astounded by these posts. Java has two modern UI frameworks. Swing and JFX. They blow Microsoft's offerings out of the water--while being proven cross-platform.
    - DaiPlusPlus 5y ago
nathell 5y ago
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/ https://github.com/HumbleUI/HumbleUI/
- Tommabeeng 5y ago
  Super excited about this. I've been using cljfx (https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx) to build a few apps and it's so developer efficient.
IE6 5y ago
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).
- lumost 5y ago
  Once upon a time Java GC was truly awful. Early versions of java lacked even generational garbage collection, meaning your app would simply hang for a few seconds every now and then while GC happened. On top of this, the performance gap compared to native code was much larger in the early days. This gave java a reputation for sluggish UIs which would mysteriously hang. In an era where new CPU generations provided meaningful performance improvements to client applications, why would a developer commit to a platform which rolled back the clock by 2 CPU generations?
  - SAI_Peregrinus 5y ago
    There was also the annoyance of having to install the JVM. And the updater never removed old versions, so you had to know to do that manually. Then Java 9 came out, but 8 didn't go away, so you needed both.
bokchoi 5y ago
This is very impressive! I haven't done ui code in a while but I would have loved to have the integrated "devtools" helpers!
- jeffreportmill1 5y ago
  Thanks! It took me a long time to figure out I needed this - now I can’t live without it!
Shadonototra 5y ago
They already have, JavaFX, there is a kotlin first framework: https://github.com/edvin/tornadofx https://github.com/edvin/tornadofx
- cryptos 5y ago
  Doesn't look well maintained.
  - Shadonototra 5y ago
    They are working on a v2 https://github.com/edvin/tornadofx2 https://github.com/edvin/tornadofx2
EnKopVand 5y ago
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.
- fulafel 5y ago
  Relatable comment. Clojure + ClojureScript has been doing the "same language on front and back" as well for a long time and a lot of the developers were not working on JVM platform before getting into the language. I think it's not a battle of languages exactly, but of battle of runtime platforms, like is now evident on the JS side as well. Kotlin and TypeScript are the mass appeal examples of this lately. But I think Clojure is the stand out one so far that is good at covering both backend/frontend and crossing between runtime platforms (JVM and JS).
nikanj 5y ago
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
- criddell 5y ago
  What's the problem with Swing that inspired JavaFX and new frameworks like this one?
  - nikanj 5y ago
    It's not new
mabbo 5y ago
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.
PaulHoule 5y ago
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.
- toyg 5y ago
  > desktop applications where the "beachball" or whited-out windows is normal and unavoidable If desktop development is "malpractice", this is actually a clear-cut case of slander and libel. Beachballs are absolutely avoidable, with some basic thread management - which is fairly trivial in any half-decent modern toolkit.
  - PaulHoule 5y ago
    How come I see them all time, especially with applications from Microsoft, Adobe and other big software firms?
    - mike_hearn 5y ago
      This is like asking why clicking buttons or links in web apps often just does nothing. You don't notice because you "know" the browser is loading the next page, you're waiting for the server and because you know that browsers don't bother displaying beachballs anymore even though the app is busy. But it's not actually any different. If you like, structure your desktop app as two threads. One does the UI. The other does processing stuff. Exchange only messages back and forth. I've actually written a desktop app this way in the past. However it's not the silver bullet you might expect, largely because expectations users have for desktop apps are significantly higher than on a web app. In particular they expect something obvious to happen when they click buttons or menu items, and they definitely don't expect long delays simply because the backend is busy. So I ended up having to introduce some shared memory and read/write locks back again, as the pure message passing model was occasionally introducing UI stalls. In a web app you'd just ignore them because standards are low. On the desktop it's like on mobile, you have to care about the responsiveness a lot more.
deleted 5y ago
[deleted]
TeaVMFan 5y ago
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!
robin_reala 5y ago
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.
- jeffreportmill1 5y ago
  It’s a huge priority, but I’d need help.
pkos98 5y ago
JetBrains "developed a new UI framework" for their new Editor Fleet: https://github.com/JetBrains/compose-jb 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.
johnwheeler 5y ago
Isn't that what JavaFX was supposed to be?
jmyeet 5y ago
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.
- funcDropShadow 5y ago
  There is jpackage in the JDK, which can build native packages for Window, macOS, and Linux. There is GraalVM which can create native binaries.
- JulianMorrison 5y ago
  If I had a do-over on Java, I'd get them to make separate interface toolkits for each major platform. Ones that use the native widgets and follow the native conventions. Design them to feel as similar to program as possible, within that limitation. Share stuff that can be shared, but don't force it if it's not as similar as it looks. Then after that maybe add a cross-platform toolkit that doesn't try to look or feel local, but treat that as a peer with the other UI kits, not a replacement.
- amelius 5y ago
  > You can make buttons look like Windows buttons on Windows and OSX buttons on OSX but that's only superficially cross-platform. Sorry, but the problems you are talking about are first-world problems imho. If the button looks like a button, and clicks like a button, what is the problem really?
cryptos 5y ago
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=aspnetcore-6.0 https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=as...
johnwheeler 5y ago
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?
- TeaVMFan 5y ago
  SnapKit is a huge framework with lots of functionality. One key part for the browser integration module (SnapTea) is TeaVM https://github.com/konsoletyper/teavm https://github.com/konsoletyper/teavm TeaVM converts Java code to run in the browser. It provides the ability to call JS functions to access browser features like canvas and XHR. However, unless you want to be coding like Vanilla JS, you'll want a framework on top. SnapKit provides that.
- jeffreportmill1 5y ago
  Not an applet at all! Apps are easily compiled to JS, including needed runtime, so it’s running native. And only 1MB compressed.
splittingTimes 5y ago
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 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 https://youtu.be/5THQMr5SAH0
- ab_testing 5y ago
  Very impressive to do this in Java FX. Did not know that you could do something like this in JavaFX
mcculley 5y ago
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.
ldargin 5y ago
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.
rzwitserloot 5y ago
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".
cat_plus_plus 5y ago
Isn't it pretty much Android? Already runs on Chromebooks and Windows with unofficial hacks for other platforms, including browsers.
atx42 5y ago
I call it Flutter!
mike_hearn 5y ago
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?
- jeffreportmill1 5y ago
  No, ReportMill is 100% SnapKit, though inspired by Swing/JavaFX. You’re right though, I could use the touch of a graphic design pro. :-)
pipeline_peak 5y ago
> 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.
- nijave 5y ago
  >users don't really care about these things I think they do implicitly. Employees definitely care when their 5 year old mid/low-end machine slows to a crawl because each chat & business app takes 600mb+ of their precious 8GB of RAM. It'd probably help if Electron was "dynamically linked" instead of each app vendoring their own version
  - pipeline_peak 5y ago
    I think as these things become more noticeable, the Electron team will make more active attempts to share resources amongst Electron "sessions". But this whole thing rides on the back of Chromium, and I have a feeling they aren't as communicative as the NodeJS and V8 developers are. Hopefully I'm wrong and in the future Blink will be more optimized for Electron.
dig1 5y ago
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.
didip 5y ago
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.
iamcreasy 5y ago
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.
hulitu 5y ago
No. Modern UI is crap.
mbfg 5y ago
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.
AmpsterMan 5y ago
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.
istillwritecode 5y ago
Let Java die a slow corporate death and assume the role of COBOL.
malteg 5y ago
I used Vaadin (vaadin.com) for some web ui back in the days. You can always bundle it somehow into an electron app...
asteroidp 5y ago
Java has needed that since day one of it's release
candiodari 5y ago
How does one develop with Snapkit? Do you have a workflow example.

thedougd 5y ago

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.

teknopurge 5y ago

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.

jeffreportmill1 5y ago

GitHub: https://github.com/reportmill/SnapKit https://github.com/reportmill/SnapKit Demos: https://www.reportmill.com/snaptea/ https://www.reportmill.com/snaptea/

fillskills 5y ago

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.

gjvc 5y ago

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 https://news.ycombinator.com/item?id=25978053) What limitations have frustrated you the most in working on this?

jeffreportmill1 5y ago
Yes! TeaVM is an under appreciated absolute jewel! The big challenge was having to write most of a UI kit to basically abstract Swing. But there is a surprising symmetry between basic Swing+Java2D and HTML 5.
- gjvc 5y ago
  Well, congratulations for the SnapKit project so far. I have now got my project to tinker with this weekend. :-)

deleted 5y ago

[deleted]

stuaxo 5y ago

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

jeffreportmill1 5y ago
Thank you for that - that's why my promising career in graphics design went kaput. I'll hire a professional for version X. :-)
- digisign 5y ago
  It looks just as it should look, ignore content-free criticism.

sidcool 5y ago

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

simonw 5y ago

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

jeffreportmill1 5y ago
Thanks! The ReportMill design app was the major driver of this.
- qorrect 5y ago
  To me the SnapBuilder is huge, bravo.
fillskills 5y ago
Wow very impressive indeed
robertlagrant 5y ago
Wow that's awesome.

danielvaughn 5y ago

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?

TeaVMFan 5y ago
SnapTea leverages TeaVM https://github.com/konsoletyper/teavm https://github.com/konsoletyper/teavm to convert Java to JS. However, SnapKit provides an entire UI framework layer too, enabling app portability to other environments (like the desktop JRE).
jeffreportmill1 5y ago
TeaVM compiles to JS and includes the basic JRE runtime. Still very lightweight!
- danielvaughn 5y ago
  Oh that's an interesting approach. I'm really into these kinds of projects because I'm trying to create a "design language" - a DSL built specifically for UI/UX designers. The idea is to provide them with something kinda like CSS, but using their own vocabulary and mental models. My thinking is that if they can write code describing interfaces in a way that makes sense to them, then all a developer would have to do is wire it up with behavior. No more handoff or recreating UIs from design mockups.

hankman86 5y ago

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.

lumost 5y ago
Aren't android UIs predominantly Java?
- DaiPlusPlus 5y ago
  Android's "native" UI library has hard dependencies on key components of the Android OS that go far beyond what can be provided by any random Java JVM/JRE (i.e. you can't simply use Android's UI .jars almost anywhere like we can with AWT and Swing). Saying "Android's UI is Java" is like saying "Apple's macOS Cocoa is x86" - technically true, but belies the sheer volume of transitive dependencies.
  - mike_hearn 5y ago
    That's true of classic Android UI, which isn't that great anyway. The new JetPack Compose ui toolkit is cleanly abstracted from Android and works on the desktop as well.
- datavirtue 5y ago
  Yeah, as are some of the most popular and modernized desktop apps. I'm always astounded by these posts. Java has two modern UI frameworks. Swing and JFX. They blow Microsoft's offerings out of the water--while being proven cross-platform.
  - DaiPlusPlus 5y ago

nathell 5y ago

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/ https://github.com/HumbleUI/HumbleUI/

Tommabeeng 5y ago
Super excited about this. I've been using cljfx (https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx) to build a few apps and it's so developer efficient.

IE6 5y ago

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

lumost 5y ago
Once upon a time Java GC was truly awful. Early versions of java lacked even generational garbage collection, meaning your app would simply hang for a few seconds every now and then while GC happened. On top of this, the performance gap compared to native code was much larger in the early days. This gave java a reputation for sluggish UIs which would mysteriously hang. In an era where new CPU generations provided meaningful performance improvements to client applications, why would a developer commit to a platform which rolled back the clock by 2 CPU generations?
- SAI_Peregrinus 5y ago
  There was also the annoyance of having to install the JVM. And the updater never removed old versions, so you had to know to do that manually. Then Java 9 came out, but 8 didn't go away, so you needed both.

bokchoi 5y ago

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

jeffreportmill1 5y ago
Thanks! It took me a long time to figure out I needed this - now I can’t live without it!

Shadonototra 5y ago

They already have, JavaFX, there is a kotlin first framework: https://github.com/edvin/tornadofx https://github.com/edvin/tornadofx

cryptos 5y ago
Doesn't look well maintained.
- Shadonototra 5y ago
  They are working on a v2 https://github.com/edvin/tornadofx2 https://github.com/edvin/tornadofx2

EnKopVand 5y ago

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.

fulafel 5y ago
Relatable comment. Clojure + ClojureScript has been doing the "same language on front and back" as well for a long time and a lot of the developers were not working on JVM platform before getting into the language. I think it's not a battle of languages exactly, but of battle of runtime platforms, like is now evident on the JS side as well. Kotlin and TypeScript are the mass appeal examples of this lately. But I think Clojure is the stand out one so far that is good at covering both backend/frontend and crossing between runtime platforms (JVM and JS).

nikanj 5y ago

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

criddell 5y ago
What's the problem with Swing that inspired JavaFX and new frameworks like this one?
- nikanj 5y ago
  It's not new

mabbo 5y ago

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.

PaulHoule 5y ago

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.

toyg 5y ago
> desktop applications where the "beachball" or whited-out windows is normal and unavoidable If desktop development is "malpractice", this is actually a clear-cut case of slander and libel. Beachballs are absolutely avoidable, with some basic thread management - which is fairly trivial in any half-decent modern toolkit.
- PaulHoule 5y ago
  How come I see them all time, especially with applications from Microsoft, Adobe and other big software firms?
  - mike_hearn 5y ago
    This is like asking why clicking buttons or links in web apps often just does nothing. You don't notice because you "know" the browser is loading the next page, you're waiting for the server and because you know that browsers don't bother displaying beachballs anymore even though the app is busy. But it's not actually any different. If you like, structure your desktop app as two threads. One does the UI. The other does processing stuff. Exchange only messages back and forth. I've actually written a desktop app this way in the past. However it's not the silver bullet you might expect, largely because expectations users have for desktop apps are significantly higher than on a web app. In particular they expect something obvious to happen when they click buttons or menu items, and they definitely don't expect long delays simply because the backend is busy. So I ended up having to introduce some shared memory and read/write locks back again, as the pure message passing model was occasionally introducing UI stalls. In a web app you'd just ignore them because standards are low. On the desktop it's like on mobile, you have to care about the responsiveness a lot more.

deleted 5y ago

[deleted]

TeaVMFan 5y ago

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!

robin_reala 5y ago

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.

jeffreportmill1 5y ago
It’s a huge priority, but I’d need help.

pkos98 5y ago

JetBrains "developed a new UI framework" for their new Editor Fleet: https://github.com/JetBrains/compose-jb 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.

johnwheeler 5y ago

Isn't that what JavaFX was supposed to be?

jmyeet 5y ago

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.

funcDropShadow 5y ago
There is jpackage in the JDK, which can build native packages for Window, macOS, and Linux. There is GraalVM which can create native binaries.
JulianMorrison 5y ago
If I had a do-over on Java, I'd get them to make separate interface toolkits for each major platform. Ones that use the native widgets and follow the native conventions. Design them to feel as similar to program as possible, within that limitation. Share stuff that can be shared, but don't force it if it's not as similar as it looks. Then after that maybe add a cross-platform toolkit that doesn't try to look or feel local, but treat that as a peer with the other UI kits, not a replacement.
amelius 5y ago
> You can make buttons look like Windows buttons on Windows and OSX buttons on OSX but that's only superficially cross-platform. Sorry, but the problems you are talking about are first-world problems imho. If the button looks like a button, and clicks like a button, what is the problem really?

cryptos 5y ago

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=aspnetcore-6.0 https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=as...

johnwheeler 5y ago

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?

TeaVMFan 5y ago
SnapKit is a huge framework with lots of functionality. One key part for the browser integration module (SnapTea) is TeaVM https://github.com/konsoletyper/teavm https://github.com/konsoletyper/teavm TeaVM converts Java code to run in the browser. It provides the ability to call JS functions to access browser features like canvas and XHR. However, unless you want to be coding like Vanilla JS, you'll want a framework on top. SnapKit provides that.
jeffreportmill1 5y ago
Not an applet at all! Apps are easily compiled to JS, including needed runtime, so it’s running native. And only 1MB compressed.

splittingTimes 5y ago

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 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 https://youtu.be/5THQMr5SAH0

ab_testing 5y ago
Very impressive to do this in Java FX. Did not know that you could do something like this in JavaFX

mcculley 5y ago

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.

ldargin 5y ago

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.

rzwitserloot 5y ago

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

cat_plus_plus 5y ago

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

atx42 5y ago

I call it Flutter!

mike_hearn 5y ago

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?

jeffreportmill1 5y ago
No, ReportMill is 100% SnapKit, though inspired by Swing/JavaFX. You’re right though, I could use the touch of a graphic design pro. :-)

pipeline_peak 5y ago

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

nijave 5y ago
>users don't really care about these things I think they do implicitly. Employees definitely care when their 5 year old mid/low-end machine slows to a crawl because each chat & business app takes 600mb+ of their precious 8GB of RAM. It'd probably help if Electron was "dynamically linked" instead of each app vendoring their own version
- pipeline_peak 5y ago
  I think as these things become more noticeable, the Electron team will make more active attempts to share resources amongst Electron "sessions". But this whole thing rides on the back of Chromium, and I have a feeling they aren't as communicative as the NodeJS and V8 developers are. Hopefully I'm wrong and in the future Blink will be more optimized for Electron.

dig1 5y ago

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.

didip 5y ago

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.

iamcreasy 5y ago

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.

hulitu 5y ago

No. Modern UI is crap.

mbfg 5y ago

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.

AmpsterMan 5y ago

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.

istillwritecode 5y ago

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

malteg 5y ago

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

asteroidp 5y ago

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

candiodari 5y ago

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