Graphics for JVM
tonsky.me
tonsky.me
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.
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.
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?
There are however, a couple of small companies, and some individuals using it, and providing contributions.
Gluon also provides builds for LTS and latest here: https://gluonhq.com/products/javafx/
(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)
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.
Yup, there is the difference. My target audience are common people, so I have to care more.
The people who care about "looks good" are managers and designers because they never actually have to use the damned thing.
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.
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.
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.
Case in point: people still use Windows, and I've never had anyone tell me it's because it looks good.
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.
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.
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.
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?).
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.
You mean Qt?
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.
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.
Things that cost me a line in CSS, like text-shadow, probably would require me to implement a shader libary in swing.
Not in JavaFX where such shaders are pre-canned and there's a CSS dialect too. I wrote my web-like app in JavaFX. It was no big deal.
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.
and of course vt100 escape sequences for some reason.
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...
It's also worth pointing out that creating a cross-platform API is better for new players than for entrenched ones.
They are all you have if you don't know about FLTK, QT, Juce, GTK, wxWidgets and many others.
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.
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.
I guess what I'm alluding to is something like CSS for desktop apps. I tried to tweak stock L&F a few times (not my choice) and I mostly failed.
Back in the day, there was a guy, Sven?, that crafted amazing L&Fs. I dimly recall he had one that was easily customized.
JavaFX supports CSS styling.
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.
[1] https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/...
Main benefit to me is deflecting spurious input. All that Drive By Management.
Instead of explaining the history of ergonomics, the philosophy of ethnography, and our reams of data from usability testing, I'd just point at Apple's Human Interface Guidelines.
Like name dropping Aristotle in debate class.
More serious actors will try harder, lean in.
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.
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.
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.
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.
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
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.
Java Web Start (JNLP) worked great. It just worked. His customers loved him.
I've always wondered why something like desktop JNLP didn't happen.
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.
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.
Wasn’t that Marimba/Castanet?
A.) ...they never figured out a good/unobtrusive update process for the JVM itself.
B.)...Sun faltered when they picked up steam. (Remember when IBM threw 1 billion USD at writing Eclipse in Java?)
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 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.
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.
VsCode and atom are simpler, but they just don't provide UI, for many setting you have to go to config files, and some functionality is missing outright.
Can you think of an IDE with better UX?
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.
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.
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.
I tried to do the same few years ago, couldn't find a reliable way.
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.)
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.
edit: fixed formatting
Have you ever used the merge tools? So dang cool.
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 :(
How are you doing this? I haven't seen any merge tool, let alone a standalone one, in the JetBrains toolbox. What am I missing?
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.
TBH I never got on with PyCharm and still use Sublime Text... but I keep PyCharm installed just for the mergetool!
If the JVM based apps do not yield a significant performance benefit then there is no point in going after that.
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.
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.
>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.
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.
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)
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.
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).
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.
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.
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.
Debatible, argueable.
In fact VSCode starts faster.
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.
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
> 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.
[1]https://github.com/scgray/jsqsh [2]https://github.com/xo/usql
I generally use pgcli for talking to postgres, and I occasionally need sql developer for Oracle - but with Bk i might standardize on it for ms sql server, postgres and sqlite.
It's foss and electron. That it's snappier than sql developerto start isn't saying much... I guess.
https://www.beekeeperstudio.io/
https://github.com/beekeeper-studio/beekeeper-studio
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..
me too :) I installed it but didn't connect to any DB yet. Startup time is certainly no better than DBeaver though.
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.)
https://www.jetbrains.com/lp/compose/ shows a code editor prototype.
Because the project is in alpha? And it says so on the page?
To quote from the article on skia:
--- start quote ---
We are so used to things we can hack together in a week, nobody is thinking in terms of years. And good UI requires years of work. It’s a big commitment.
The road to high-quality UI on JVM is a long one. We’ll need:
- a graphics library,
- a window/OS integration library,
- a UI toolkit.
--- start quote ---
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"
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 think you've got the wrong end of the stick. The author isn't suggesting anyone do this.
But most apps need to do some drawing of their own - if they're a charts library, or a CAD program, for example. Then you need a library like this.
"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.
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.)
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.
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.
> 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.
Well, yeah... which is my point.
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.
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.
I think the author is trying to get to a wonderful future but their heading in totally the wrong direction.
This statement betrays the commenter's lack of understanding understanding of both limitations of the Web model and the freedom afforded by almost every single one of UI libs and frameworks.
> I don't even understand what he tries to say with "draw the control directly".
Aaand here it is: "I don't understand".
In a GUI framework/lib you usually have the ability to skip the provided primitives and draw whatever you want directly. A framework/library doesn't provide a control you need? You just draw it yourself.
So, instead of re-inventing, poorly, a virtual list, or a calendar, or a customisable drop-down with a few thousand divs, z-index issues and layout thrashing, you can (relatively) easily implement those controls yourself. At easy 60 or 120 fps.
> I don't in general buy the argument that the DOM is low-performant and low-quality. Lots of great and performant UIs have been built on the web platform.
Name a few, please. And when you look into those "performant UIs", you'll see on or more of:
- skipping the DOM entirely and building everything on top of canvas or webgl
- going through great pains to: avoid mutating DOM, avoid repaint/reflow (which can happen by simply querying the DOM [1]), reducing the already laughably small amount of updates even further to prevent DOM updates, layout thrashing, JS GC pauses etc. etc.
And this will still not come even close to, lets say, displaying a million objects on screen at 120fps (any modern game engine), or any significantly complex UI layout (any professional app).
[1] https://csstriggers.com and https://gist.github.com/paulirish/5d52fb081b3570c81e3a
> 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.
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.
HTML5 canvas?
--- start quote ---
... when you look into those "performant UIs", you'll see on or more of:
- skipping the DOM entirely and building everything on top of canvas or webgl
...
--- end quote ---
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.
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 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.
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.
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 really. That's the point of making components in React/Vue/Svelte/etc, you can create reusable modular parts.
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 ?
Just right now I'm building a component that abstracts filtering and sorting for lists of items in Svelte.
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.
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).
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.
Apart from the fact though that your understanding of a toggle on the web is switching visibility on images instead of building the button how the design wants it and not unnecessarily load images shows that you not only sound quite like an ass but are also so stuck up that you think your understanding is good enough to compare your experiences.
Hint: It's not. Get over yourself and maybe put on a gentle tone next time you're trying to make a bad argument.
This is also pure gold that I can't believe you actually would do
> start with a div
Let me know about how would you implement it in 1 minute, I want to know because it seems I missed this method you are speaking of and I really need to learn it.
What was such terrible about "start with a div" all components I seen so far start like that see for example https://getbootstrap.com/docs/4.0/components/dropdowns/
Honestly I am not sure what triggered you, I had a nice dialog about what is missing with the DOM , the other comment acknowledge my point and I am confused by your aggressive tone(english is not my native language so did I used the wrong word or what triggered this response?)
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.
still waiting to see them, at least for performance levels comparable to 2007 desktop apps
Also, does the DOM have a ListView/TreeView?
This must be some strange usage of the word 'performant' I wasn't previously aware of.
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.
It's been some years that I don't do anything web so I'm not sure if I'm familiar with its problems.
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, ...)
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.
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.
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.
I would like to have an opinion on this myself but I've yet to find a JavaFX application in the wild.
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.
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.
https://github.com/geokon-gh/corascope/
I even managed to make a little SVG backend for it
That said - this seems to be more of a " graphics library " while JavaFX is more of a " user interface library ". I'm sure there is a ton of overlap - but I wouldn't be making funky creative coding displays directly in JavaFX
My minor annoyance is that it's nearly impossible to make something that runs on Android out of that - which seems like a giant shame given it's all JVM
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.)
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.
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.
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.
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.
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.
I think the Nimbus look is ok. [0]
> It is still heavy, although start up speed are now better.
It's certainly heavy. iirc NetBeans spins up over 20 threads even if you're not doing anything. As for startup times, is this on the same hardware? I imagine SSDs must help with NetBeans startup.
> trying to use GCJ and SWT for Desktop Apps then, it was just too hard.
There was a proprietary payware alternative to GCJ called Excelsior JET but it was discontinued 2 years ago. [1]
[0] http://wiki.netbeans.org/wiki/images/b/b2/Vista_Nimbus_Scree...
Well, not exactly. https://github.com/JetBrains/skija/ is 30% C++ and of course requires native builds: https://packages.jetbrains.team/maven/p/skija/maven/org/jetb.... If you are lucky, Maven simply hides it from you.
UPD: no, it doesn't hide it. See https://github.com/JetBrains/skiko/blob/master/skiko/build.g... and search for 'lin'/'mac'/'win' and see for yourself.
UPD2:
@-moz-document domain("tonsky.me") {
body {
/* surovyi background color off */
background-image: none;
background-color: hsl(0, 0%, 85.9%);
}
}Ideally we won't when the JVM gets an FFI built-in.
JNI needs binary blobs. The new FFI won't. So we will not need binary bobs when we get the new FFI.
See?
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?
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?
[1] https://en.wikipedia.org/wiki/Processing_(programming_langua...
Oh BTW, you can do WASM with Blazor (C#) now.
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)
[1] Links under "Maven Artifacts": https://www.eclipse.org/swt/
[2] https://mvnrepository.com/artifact/org.eclipse.platform/org....
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 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.
https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
If I could get an example written in Clojure that'd be even cooler :)
I noticed they have this: https://github.com/JetBrains/skija/blob/master/shared/src/ma...
Is rendering SVG in the pipeline? It seems within the scope of a graphics library.. or maybe not?
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.
--------
Is desktop still relevant?
I believe it is!
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'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).
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...
Is it?
Looking at these benchmark they seem to be in the same ballpark for most results:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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.
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.
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).
(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)
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.
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.
Its pretty fun. Also its javascript cousin p5.js
I'm thinking this is more UI focused.
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.
https://blog.jetbrains.com/cross-post/jetpack-compose-for-de...
https://www.reddit.com/r/java/comments/jrqjex/whats_being_us...
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.
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..
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.
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.
All that while C# is booming on indie game dev.
The repo seems to have very recent activity, has commits from today! https://github.com/openjdk/valhalla
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.
Is this a windows/linux specific problem?
My point being that, Skia is great but is not the most important ingredient at play for Flutter achievements.
Also being a good choice will not pay for the bad choice that is choosing JVM as a primary platform for this which targets UI application consumers.
[1] https://docs.oracle.com/en/java/javase/11/tools/jlink.html
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
> 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.
> And I’ve been on both sides. I lived without a desktop for a few weeks once.
Mobile platforms, on which selecting and searching text is hard, switching between tabs is slow and multitasking between apps is made complicated by:
> By the time you found what you needed and returned to the calendar, it has been unloaded from memory and all context is lost
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)
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.
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..
Do you mean .NET would do too?
https://news.ycombinator.com/item?id=21192321
Admittedly this was a year ago! Time flies...
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.
Though did anyone else notice the little "sun" slider at the top of the page for the spotlight in html? Useless but fun.
I like yellow, and I like this website: it is simple and to the point.
There is some truth in this sentence.
>Why not Electron?
> 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.
That gave me a chuckle
Ah the irony
An electron app of that complexity would require a supercomputer to even start