Hacker News Reader

Comment by palata | Hacker News Reader

> One of the main core differences with Tauri is that it uses a Webview instead of using chromium like in Electron. This means that every desktop application doesn’t have to ship with chromium and can rely on the native browser’s webviews. The downside here is that because it is using Webview you have to deal with different quirks of different operating systems.

ElectronJS is a cross-platform framework. It is bloated because it ships a full cross-platform browser (Chromium) in order... well in order to be cross-platform.

Tauri wants to be less bloated, and therefore removes Chromium. Which makes it... not so cross-platform, apparently.

Genuine question: why not going for a JVM-based technology? That's cross-platform, and it doesn't require a web browser / webview to show text.

View on HN

> why not going for a JVM-based technology?

Not to pick on the JVM, but does anyone actually build new desktop software for the JVM that's meant to be downloaded and installed by mainstream consumers? Qt and other frameworks work pretty well (with their own flaws) but I'd simply never even consider the JVM as a viable option for desktop software. The last JVM app I installed was probably Minecraft in 2012.

exception to the rule, and should be popular on this site: IntelliJ IDEA (and derivatives) are JVM based.

I use IntelliJ, which is a Java + Swing app I think.

Initial release was 2001

Looks like Java is working pretty well for them then.

Ok the other hand jetbrains is developing new IDE - Fleet, that’s supposed to compete with VSCode - not sure if it’s written using JVM stack for that

https://blog.jetbrains.com/fleet/2022/01/fleet-below-deck-pa...

While Fleet is still a JVM app at it's core, it's true that it apparently no longer uses Swing for the UI components. Instead they seem to have reinvented that wheel with their own UI component library called Noria (also JVM) and render it to the screen with Skia (a native 2D graphics library - non JVM).

Pretty fun stuff.

https://blog.jetbrains.com/fleet/2023/02/fleet-below-deck-pa...

LibreOffice is still built on Java, that's probably the main consumer app that still is. Of course, there are developer tools like the Jetbrains IDEs still running on the JVM, but those aren't for mainstream consumers.

Nowadays it can be hard to tell if something uses Java, since it's recommended to just bundle a JRE with your app so a user doesn't have to know/care about Java.

LibreOffice has very little Java code. https://www.reddit.com/r/libreoffice/comments/6gxy82/is_libr...

… and it’s all optional; has always been, I believe.

There are more than a few decent Java GUI apps out there, some built with swing, some with JavaFX, some with SWT, maybe we will soon see some using jetbrains compose. I would say that the developer experience isn't bad at all, but if you want to make a very complex or unique application, you will want to surround yourself with someone who knows those stacks very well (just like any other tech), the problem being that it's a dying breed.

If you want to make a small to mid-scale GUI, I'd argue that you'll be better off with a java toolkit than anything web based (tooling is awesome, there are RAD tools to prototype and iterate quickly, ...). The alternative I see in this space is PyQt/Qt for Python, but it's easy to shoot yourself in the foot with it and everyone knows how terrible packaging and shipping python is.

For me it's probably Ghidra or Jetbrains IDEA in 2023. Both are desktop, thought I could see the debate on whether or not developers are considered mainstream consumers. I use them on Linux and Windows, so I definitely get value out of their cross platform capabilities.

I use Eclipse-based tools at work (again, I can see the debate). It seems like Samsung's Smarthings (IoT platform) used to use Groovy, but has recently migrated away.

I also know you said desktop, but a weak argument could be made in favor of the (also weak) JVM connections of Android. I'd put forth that some Android usecases are basically former desktop usecases.

Its never fun finding the correct java version to get ghidra going on a new machine. I don't use java often enough to remember versioning differences between the official and openjdk. I never install the right one on the first try, always requires a trip to the ghidra docs.

I must have gone through this 7 or 8 times in the last 5 years.

Its also really rare for a desktop app written in java to look good. I'm sure its possible, but man looking at ghidra is a real pain.

I thought openjdk is the "official" version of Java now (besides Java EE)?

Here’s a compilation: https://sdkman.io/jdks

They have recently introduced support for UI theming in version 10.3 released last month.

> Its also really rare for a desktop app written in java to look good.

Java/JVM as platform suffers from trying to be all encompassing "second OS". Want to do time, fonts, cacerts? JVM does its own thing. Want to do UIs? Hey, there are widgets from 90s, should be good.

Looks like crap, but everywhere!

These days Ghidra usually works fine on any of the last 3-4 Java versions.

Don't JetBrains just ship with their JRE and always ignore any "system" JRE? That feels like the correct solution, at least once your app gets to a certain size so the size of the JRE can be ignored. Also JetBrains' apps look good enough I'd say.

Another pretty one with a java frontend is BitWig. That's perhaps more impressive than any JetBrains app.

IntelliJ can have its own dependency hell, don't worry. Not so often but it happens.

Last time I upgraded an old install i wasn't using, it pulled its own JRE, then pulled a new gradle which promptly complained about the JRE Android Studio installed itself.

Had to do some googling and force it to use a JRE that both the IDE and gradle liked.

But as I said, that doesn't happen often. It's just funny when it does, in a masochistic sort of way.

We have a surprising number of customers who ship JVM desktop apps, mostly in industrial control and robotics of various kinds.

Yes we have 15k users

I'm sorry to say that you're not a mainstream consumer app with only 15k users

> Not to pick on the JVM, but does anyone actually build new desktop software for the JVM that's meant to be downloaded and installed by mainstream consumers?

Does anyone actually build new desktop software for mainstream consumers these days?

JVM UI is "good enough", I've seen it used for businessey tools where the point is the functionality rather than the polish (including hobby tools). Honestly it may well be the best non-electron option once you think about the whole stack; with Qt you have to either write C++ and deal with that, or use the Python bindings and deal with that.

> Does anyone actually build new desktop software for main stream consumers these days?

You’re in a thread about some people that built a new piece of desktop software…

I've got Notion, Spotify, the app for my insta360, Slack, linear, Final Cut, and VS Code open right now. As best as I can tell, half are Electron and zero are JVM.

I do Java desktop, using JavaFX. But I’m nobody.

I will say that my dev cycle builds (full clean and rebuild) take about 20s, which is nice. That nets me a “runnable fat jar”. Running the packager for the platform installers takes longer on top of that, but that’s not part of my dev cycle.

I dev on macOS, I have “tested” on Ubuntu and Windows, and the app works. My buttons button, cut and paste works, drag and drop (I can drag one of my generated images and drop it into, say, Word) works, I can generate PDFs via the “print to PDF” features of the platforms, including my custom fonts. I also have, like, 10 lines of code that uses JavaFX 3D — and that works.

It all works, and so far, knock on wood, the “cross platform” parts are doing what they’re supposed to do.

All that said, germane to the overall topic, there’s this funny little tidbit. In my app, all my bundled documentation is simply in HTML using bundled pages. And I show that in a JavaFX WebView. And WebView is built on WebKit. So in the end, if you need any HTML in your app, you bundle WebKit anyway.

Of course, if you don’t, WebView is in its own module that you don’t have to ship if you don’t need it.

Jetbrains does. Millions of developers are using a swing ui and don’t even know.

A lot of modern consumer and business oriented GUI apps run on JVMs and they look very platform native too. In finance, I’ve come across many of them. You can take a look at the upstream demo apps for Swing with FlatLaf and for JavaFX (rebranded to OpenFX). They perform nicely. I’ve been struggling with the JetBrains tools’ performance on large JVM projects but given the complexity and reindexing it’s justified, Visual Studio would simply hang indefinitely on such code bases, VS Code just doesn’t do this much.

Then there’s also Kotlin Multiplatform and Jetpack Compose, and now Compose Multiplatform (desktop, mobile, web including JS and WASM). Their DSL is really amazing, truly compositional and resembling the way you do React. To me that’s the path cross-platform GUI will be taking now.

On the .NET side, there’s Avalonia UI and Uno Platform as cross-platform alternatives, with Avalonia UI v11 (pending release) even doing mobile on almost the same code base.

JavaFX/OpenFX is surprisingly decent these days, but it got suckerpunched by Oracle licensing for a long time and had a bunch of compatibility issues between releases that made upgrading painful.

I probably would consider it now for a new project, but not 5-10 years ago, when dev cycles for now-popular apps would've started realistically.

I, for one, am looking forward to the evolution of stuff like Compose for Desktop. Kotlin + Compose on Android is just amazing, I wish it worked as well on Desktop.

Also the JetBrains IDEs are really good IMO.

IMO native widgets are dead. Users have become accustomed to the graphical gimmicks that are easy with a full-blown browser rendering engine.

Even a resizable background image is really hard to do with pure native widgets.

This means cross-platform libraries that wrap native widgets are dead as well. Now you need to ship your own rendering engine, and suddenly an entire browser looks reasonable. E.g. JavaFX isn't a featherweight either...

The web browser is a feature, it allows developers to not have to code a second UI for their app, when they often have already built a web version. And it neatly end runs around having to make a cross platform UI toolkit that doesn’t look like hot garbage on every platform.

I guess we aren't aware of any Electron alternatives built with JVM. We started out as a web app so we need something that would bundle web based technology. Besides electron Tauri seemed like it was the next best bet.

I'm curious if you would have considered it if there was a Tauri-like thing with a JVM backend (maybe natively compiled AOT)? That is, if you could write "backend" code in a high level GCd language whilst using HTML/CSS as the UI layer, would that have been preferable to Rust?

Asking for a friend, of course.

The JVM being truly cross-platform was a bit of a lie depending on what you do.[1]

"Java is write once, test and debug everywhere."

Also the ui toolkits for JVM ecosystems are just not as nice to develop with. But I was pretty hardcore C#/.net back in those days so take what I say there with a grain of salt.

[1] https://softwareengineering.stackexchange.com/a/20024

Or why not use Flutter? You can integrate with Rust as FFI via flutter_rust_bridge. That's what I do as Flutter is pretty cross platform yet much leaner than even using a browser engine.

A good idea. I think Flutter loses quite badly to React for web apps. But if you want to build a cross-platform app it works well. Dart is similar to Javascript and not difficult to pick up.

> Tauri wants to be less bloated, and therefore removes Chromium. Which makes it... not so cross-platform, apparently.

It's certainly cross-platform. Name a current OS that doesn't have one WebKit-forked webview or another available at all times. If you don't like Apple's insistence on only baseline WebKit out of the box, there's Microsoft's WebView2 which ships a known Chromium to every major desktop OS.

But really, if you are a web developer complaining about the differences between WebKit and Chromium, you may be spoiled. If you are a web developer complaining that you can't package a specific Chromium version (which is the real Electron benefit, not just that it packages its own Chromium but that every Electron app can pick and choose down to the exact Chromium version they want to ship), you've gone beyond spoiled to basically distrusting how the web platform is supposed to work.

(That's before you get to the other monoculture assumptions that no modern OS is instead shipping something like Firefox as the system default webview in 2023. It's all one tiny family tree with WebKit as the trunk.)

If you offer developers the choice of either embedding a whole web browser and not dealing with platform differences, or not embedding a whole web browser and dealing with differences between the now-evergreen browser engines on each major platform, many may pick the latter to be more user-friendly. I certainly would.

But as long as you’re maintaining a webapp anyways, you still have to do all that browser support. Using tauri doesn’t make it worse than a webapp that only runs in a browser context.

Exactly; electron only gives you a benefit on that front if you don't otherwise have a need to be portable.

You mean the former?

No, I mean the latter: picking "not embedding a whole web browser" is worth it for the user-friendliness, even though it means having to deal with those browser differences, which have grown a lot less onerous than they used to be.

Chromium or Tauri, you are still building platform specific binaries either way.

Sure but with Electron you don't have to worry about browser differences. And you can use experimental web stuff.

If your app is primarily a website and you want to wrap it as an app then I guess Tauri makes some sense. E.g. something like Slack or Gmail.

If you're just using it as a way to make a desktop app then it makes more sense to use Electron unless your UI is very simple and download size is very important (e.g. something like the Raspberry Pi Imager app; though that uses QtQuick).

> why not going for a JVM-based technology? That's cross-platform, and it doesn't require a web browser / webview to show text.

Because then you require the user to install a JVM?

You've been able to package your java apps so to not require that from your users for a very long time, and in the more recent years, with the compartmentalization of the JDK, you've been able to ship a very striped down version of it, and even more recently, an AOT compiled/PGO optimized binary, so nowadays you can ship your instant starting/low footprint/well performing java code without Java/a JVM.

It's been years since I've messed with Java. OpenJDK can do all that? How big are the binaries?

JLink (JEP 282) does the first part and was released with Java9 (6 years ago), the native compilation stuff is a product of GraalVM. Binaries are reasonably small but it depends of course on what your app is doing. There is a whole ecosystem of web frameworks that's being built on that (quarkus.io, micronaut) and IIRC you can build a simple REST API that ships as a <20MB container.

They're pretty big. I've got a fairly basic JavaFX app that's compiled with Graal, and it weighs in at 98MB, or 32MB when zipped.

Nobody is going to blink at a 98MB program being installed...

Not too surprised, but aren't you incidentally also bundling chrome/WebKit on top of that by depending on WebView?

JavaFX supports a WebKit based WebView widget, but it's optional. If you don't use it it's not bundled. If you do then you pay the cost of including the WebKit build which is ~80mb.

In practice the need for WebKit is going down over time. For basic rich text you can render Markdown to JavaFX nodes directly, for more advanced stuff you could transform [X]HTML to FXML, you don't need it for video or audio, there's a native rich text / word processor control these days, and if you can do 3D graphics with a high level scene graph (meshes, lights etc) then you don't need HTML for 3D either.

Still, it's often useful and bandwidth/disk space isn't the problem it once was.

Are you the Mike Hearn from the bitcoin and "history is a scam" fame? Cool to see you here :) I somehow am (positively!) surprised to see your name in relation to Java GUI frameworks. Hydraulic Conveyor looks interesting, is it planned to support GraalVM's native-image? Would it work with Scala/ScalaFX?

Haha, it's amusing that the history essays are one of the things you remember :)

Yes I think you can compile Scala and ScalaFX apps down to native binaries this way. Look at Gluon Substrate:

https://github.com/gluonhq/substrate

One of our customers is experimenting with shipping such apps with Conveyor. There's a discussion ongoing here:

https://github.com/hydraulic-software/conveyor/discussions/6...

We got a console hello world working, albeit the DX is a bit rough. You need some ugly config boilerplate and some additional Native Image json files. But, it works, at least enough to create a Mac package with the regular Conveyor feature set. There are some limits though. I think the WebView doesn't work when the app is natively compiled this way. There's also someone in our Discord who has been trying it with Compose apps.

If it all starts working well it could be quite interesting for desktop app development, as suddenly you could use high level languages and portable UI toolkits but with the sort of startup time, performance and memory usage you'd expect from native apps (modulo binary size which is still quite large). If you want to use HTML as the UI then you can use the Chromium Embedding Framework, which would give you an Electron-like experience but with many more available languages:

https://hydraulic.dev/blog/13-deploying-apps-with-jcef.html

For a Slack competitor like Linen it would make more sense to use web UI because of the video calling/WebRTC stuff. OTOH if you don't care about that, it'd be (imo) easier and more direct to not use HTML. Proper GUI toolkits give you a lot of stuff out of the box like virtualized list views which HTML still doesn't; useful for scrolling over huge datasets like chat logs.

I've been using JVM GUI for years for various tasks. It was appropriate for Bitcoin tasks because it's immune to injection attacks, because you can run everything locally with P2P protocols like the original Bitcoin app did, it's portable etc. Also I learned GUI programming decades ago and find classical UI toolkit concepts like VBox, HBox, StackPane, TableView etc more intuitive than HTML.

Thanks for the reply, I'll definitely keep an eye on all that.

> For a Slack competitor like Linen it would make more sense to use web UI because of the video calling/WebRTC stuff.

I'm not even sure it matters so much, for instance there is this XMPP client that uses (lib)WebRTC for audio/video calls and has all of its UI build with Gtk (no web): https://dino.im/

> Proper GUI toolkits give you a lot of stuff out of the box […] Also I learned GUI programming decades ago and find classical UI toolkit more intuitive than HTML.

yep, looks like we are on the same boat of angry old men yelling at clouds :)

OpenJDK doesn't do the AOT compilation part, you have to use GraalVM native-image for that and it's somewhat experimental for desktop apps. But otherwise it's pretty easy to bundle stuff up.

1. Go grab https://conveyor.hydraulic.dev/ (disclosure: my company makes that)

2. Run `conveyor generate {javafx,compose} my-test-project` (pick your preferred UI toolkit). You now have a JVM desktop project.

3. `./gradlew jar; conveyor make site`. You now have a directory with self-updating platform native packages for Windows, macOS (ARM/Intel) and Linux that you can upload to a web server of your choice. Or supply upload creds and it'll do that step for you. Provide certificates and it'll also take care of signing.

That's all it takes to get a self-updating JVM desktop app these days. The same tool can do Electron, Flutter and native apps too (i.e. C++/Rust), so you could also use it with Tauri, but the nice thing about the JVM support is that it'll both strip down and bundle the JVM for you whilst cross-building/packaging so you don't need CI to do releases. From the user's perspective it's a normal app, from the developer's perspective you just hack on your local dev laptop like you could for a web app.

Binary sizes depend on how much functionality you use and how much effort you put into minifying. With the default level of effort (i.e. none) a simple hello world JavaFX desktop app will be about 33mb and a simple compose app will be about 52mb for macOS (skia is a very large graphics library). However, the Mac versions are larger than those for other platforms, and these sizes are still quite wasteful. There's a lot of low hanging fruit. You could make it a fair bit smaller by using ProGuard and other more aggressive dead code elimination techniques, as well as more heavily compressing bytecode. There's also plenty of fat to trim on the native code side.

GraalVM native images are interesting because they have much faster startup time and low memory usage - competitive with C++ apps, even. They take more work to create though. You can see a robotics app that's natively compiled here:

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

I’ll have to check this out.

So your suggestion to avoid shipping chromium is to ship java instead?

Aren't you just replacing one VM for another?

At some point you need to ship the runtime, right? Even native (Go, Rust, C++, …), depending on how you do the linking. What would make it more acceptable in this case is that you would strip down the JVM and only ship the modules depended upon (whereas Chromium is a monolith) when using jlink, and on top of that, native-image does some PGO, inlining and dead-code elimination AFAICT.

TIL, I haven't been using Java-based software for a long time (and I still have vivid memories of having to install the correct version of the JDK before installing one).

Because of Oracle?

Reply on news.ycombinator.com