So no, a new UI toolkit is not going to revive Java in the mainstream.
So no, a new UI toolkit is not going to revive Java in the mainstream.
Indeed, I'd argue that apps like IntelliJ are exactly why nobody wants Java on the Desktop. I had to buy a computer with more RAM specifically because IntelliJ uses so much. Even Electron apps aren't so bad with regard to RAM usage.
Intellij would require notable memory and cpu regardless of whether or not it was Java. See XCode and Visual Studio for comparison, as they are probably closer to the same feature profile than something like VSCode would be. Their memory footprint and performance is not what I'd call substantially better than Intellij (and as with most comparisons of this nature, many caveats exist around which plugins/addons/features are in use).
Would Intellij have a better resource profile if it were native? Ya, possibly, but it's also possible that another language/platform would have been a significant barrier to long-term success. Not many cross-platform UI toolkits from 2000 to choose from, and many fewer have continued to be well-maintained and usable today.
I haven't used Visual Studio, but I think IntelliJ comes out pretty unfavourably in comparison to XCode. On my machine XCode would only slow it down when it was actively compiling (which I would expect from any compiler - it uses pretty much all of the resources of the system), whereas IntelliJ would slow it down just having it open in the background. I had to close down everything else when I wanted to use IntelliJ, or deal with a laggy system. The only other app that had a similar effect was Figma.
It's like a carpenter using a hatchet because a bench plane costs more money.
Also keep in mind what IDEA is doing with that memory. It's storing indexes to all your code and libraries for near instant bidirectional navigation and search.
Also be weary of supposed high memory usage with Java. The JVM will allocate memory from the operating system for the application but then not actually use it. It's doing this so that in the event the memory is needed, it's already been allocated to the process. I've seen other apps increase the overall memory load and the JVM then relinquish it's pre-allocated-but-unused memory.
There's projects like deno and esbuild that should help mitigate those issues, and Yarn's Plug'n'Play to reduce file amount and size overhead by using .zip files and centralized repositories. I mean it's only a patch but still.
Every organization with whom I've been affiliated since 2017 has a fairly strict policy of dependency audit. Dependencies are NOT allowed to be added unless there's a really good reason. And even then, we pay a lot of attention to what that dependency will bring with it.
Satire is dead...
Maybe I’m getting old but I’m a bit sad for all the open source apps that where abandoned over the years because the tech stack stopped being cool.
Hell, websites don’t hold up as well to time with all the missing links/resources.
"Blazor", actually.
I can only assume web technologies and electron got popular because all of the Desktop platforms where trying to jump to tablets and phones and whatever else they considered new and shiny so that while web tech was a terrible stack it was at least stable.
P.S.: I sort of hope for Griffon to make a come back. Griffon framework + Groovy + JavaFX looked nice to me.
No no no. Web tech was/is terrible, but it's dirt cheap. You can hire JS hacks by the boatload, and retrofit whatever they build into an electron app relatively easily. Whereas desktop developers are few and expensive, and they tend to optimise for this or that platform or toolkit.
Electron didn't win on quality or features - it won on the back of commercial realities of the development world.
Even way before they came out I wondered why more native apps didn’t just reuse HTML/CSS at least (many did).
Of course we all know of the downsides of Electron (basically Chromium + An App in every app; ridiculously heavy-weight.
I’m fond of the webview project and Tauri, being built on top of it. It reuses the available system browser view and doesn’t bundle Node, so it’s very light.
It's 'light' in terms of download size, it's not far off from Electron in terms of resource usage. Most complaints about Electron are about resource usage, not really download size (though there are some).
As problematic as CSS is, getting things in the right place is still dramatically easier than with Swing LayoutManagers, and when you do have problems, you have great tools in the browser to explain what's going on.
Browsers particularly shine in text rendering, naturally; text styling, font selection, word wrapping, etc. are all easily configurable. You want bold text next to regular text in Swing? You either need two JLabels, or you wrap your text in <html> tags and let the embedded HTML 3.2 renderer do it.
JavaFX has much more intuitive layout for apps than HTML and also has CSS. So you can get the best of all worlds. HTML5 has been trying to catch up with CSS flex-box, but it's all just retrofitted and shows.
Also, word wrapping? HTML is quite terrible to read compared to Latex-rendered text so I wouldn’t say that it is all that good in fonts either.
This doesn't affect the uselessness of client java as competition has also improved and java doesn't offer anything extra. If you want it quick & dirty you use electron, if you want to have it nice & smooth - QT. Desktop Java is neither a fish, nor a crab in a way.
Yes there are still niche domains that would need a desktop app but those are probably more rare as time goes on and/or already have established players.
Web apps also have major downsides. It's easy to forget about them as developers, but for example, one is the lack of versioning. Someone pushes a new version of the app that's buggy/an UI downgrade/causes an outage and the users can't do anything about it.
Often you want an app to be local because it's interacting with local data, or local hardware, or it suffers from latency, or you don't want your data to go outside your jurisdiction, or it's doing something else where distance between you and the app is problematic.
Client side apps written using normal toolkits (not HTML) have a lot of major end user advantages, which is why:
• Mobile apps beat web apps, despite devs trying to make users accept them (recall the history of the Facebook app for example).
• HTML5 keeps sprouting features that desktop apps have had since the beginning. Filesystem access is a recent example.
Any time you want your data to be independent of the apps that work with it, web apps just faceplant.
In my view developers push web apps on users usually for our own convenience, e.g. being easier to bypass IT department bureaucracy. But there's a lot of ways to do better than web apps, and yes, the JVM is pretty good platform to do that on (JavaFX is a great toolkit for instance, and JetPack Compose is very interesting). What it needs is a great distribution and update solution.
Pushing buggy/UI problematic software is a process/people problem not really a technology problem. I would bet the feedback loop for getting fixes in on web apps can be much shorter than client desktop apps (or mobile). Once a fix/change is tested we can have it out in production on a web app for 100% of users in 20 minutes.
Stand-alone apps are a great niche where the native UI kit or other UI kits that work for the problem being solved are a great solution, there isn't a need for web tooling.
An extreme example of where this matters is in the military. You cannot have an army in battle being brought to a halt because some web dev pushed a syntax error in a PHP file. You must have a qualification procedure that tests it in the scenarios that matter, which the developers may not even understand all that well.
Another example is medical software. If you push an app update to equipment in an operating theatre and a button stops rendering because the doctor had the font size wound up higher than expected, then people might die. You just cannot do that. Heck you cannot even allow it to depend on working internet. It has to be a desktop app (well, embedded, but a lot of embedded apps are just desktop apps on kiosk mode operating systems).
Now you're right that if you do push a bug, then due to all the data collection and the way browsers commingle data and code, you can fix things faster than the slower more async process preferred in the desktop world. But there's no fundamental reason it has to be that way, it's just a question of social norms. You can make a desktop app that can be force updated immediately or even on a per-screen basis. People just don't do it because often if you're writing a desktop app in the first place, it's because your users want or need more control than a web app would give them.
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.
The new JetPack Compose ui toolkit is cleanly abstracted from Android and works on the desktop as well.
Java has two modern UI frameworks. Swing and JFX. They blow Microsoft's offerings out of the water--while being proven cross-platform.
I hope you're being sarcastic there...
Swing is decidedly not "modern" at all: its active development period only lasted from 1998 ended by 2005, and saying that Swing is "cross platform" is really overselling it because it always looks out-of-place, if not downright hideous (default skin) on every platform;
While JavaFX is/was so unpopular that it was removed from Java SE and Oracle will stop supporting it by 2025.
Otherwise, JavaFX was axed from the JDK because there is absolutely no reason to tie a frontend lib’s lifecycle to that of the JDK’s. Swing could not be axed due to the insane amount of dependencies on it, but JavaFX has it in a way, better as being developed separately.
And even though it is not huge in terms of marketshare, it is doing good with proprietary solutions, cross-platform compilation to web, desktops, and both android and ios being available.
Truth is that the only advantage Desktop Java has over electron is that it is a bit faster and less leaky, but the advantage above Qt is only that you don't need to learn C++.
I mean, people seem to put up with electron these days, and the few modern JVM GUI apps feel generally better than electron stuff (for instance the all-pervasive UI latency that you get with things like vscode and slack is largely absent from IntelliJ).
Most complaints about UI toolkit in "Java" are really about the JDK, its startup time, and the fact that the UI toolkit in the AWT/Swing days never closed the gap with native apps.
Kotlin would just be using the core library UI (or android UI API), so it's no real advantage.
Kotlin compiles some of these newer features’ equivalents to java 8, that’s why it is used. But that is a failure of android, not of Java.