In Clojure you can use JavaFX through cljfx

https://github.com/cljfx/cljfx/

I haven't used React, but I think it's very similar. You have a state atom and then a datastructure that represents the GUI and associated callbacks that modify the atom. So it ends up feeling very functional. It doesn't use hiccup, but it's a similar structure. I've got to say it was fantastic. The least painful GUI programming I've ever done. The core architecture isn't opinionated so there is a little boilerplate/plumbing to setup but then it's very smooth sailing. It even has a very handy memoization structure that allows you to seamlessly have intermediary derived states that update automatically. I release an app using it and it was very performant, used some Java CV libs and drew diagrams to the canvas and it was all very snappy.

My only minor complaint was that the final bundle was like 150MB, which given the scope of the app seemed a bit gross - but it's manageable. And as usual, buy default, the JVM gobbles up and doesn't release memory back to the OS which is annoying. But i think it's surmountable and In theory you could trim that all further with GraalVM. Just out of the box it's not the best for little hello-world apps

I’ve found cljfx very productive. Steep learning curve, and the abstractions are somewhat leaky, but it’s worth the pain around the edges for the core workflow. Wrapping controls like ControlsFX is trivial. We’ve written a wrapper for TestFX as well so we have full functional tests and everything gets built, tested, jlinked and jpackaged continuously. It’s been one of the least painful projects I’ve ever worked on tbh.

Do you have any good resources on how to use jlink/ jpackage with Clojure? Do you somehow embed it in a Uberjar or is the Uberjar part of the package besides the JRE?

You build your Clojure app as an uberjar, yes. Only gotcha here is to remember "-Dcljfx.skip-javafx-initialization=true" so the JFX thread doesn't get started during build, and I've had no problems using Clojure's direct linking either. You use jlink[1] to create a custom runtime JRE image (this isn't strictly necessary if you're deploying to machines with a JRE but it cuts down on moving parts and gives you more control). jpackage[2] then takes that runtime image and your uberjar and creates installers for Mac/Windows/Linux. Both are command line tools, and we just have GitHub Actions that cut new releases for each platform when we tag something with a new version.

Worth also keeping an eye on jDeploy[3] which adds extra goodies like auto updates, at the cost of some npm shenanigans. Not something I've played with yet though.

1: https://docs.oracle.com/en/java/javase/17/docs/specs/man/jli...

2: https://docs.oracle.com/en/java/javase/17/docs/specs/man/jpa...

3: https://www.jdeploy.com/

"at the cost of some npm shenanigans"

jDeploy developer here. No shenanigans, I swear. npm just simplified things. Some have expressed interest in adding self-hosting options, so I'll likely add support for that. It's open source too, so others could potentially add other hosting options also.

Yeah sorry I didn't mean anything underhanded, it's just a complication that made me reluctant to try it out initially. Honestly if you wanted to offer a whole turnkey commercial service with hosting and analytics and stuff I could imagine being drawn to that.

Thank you for the tips! At OrgPad, we currently use the system-wide JRE since we control the whole VM, this is not a huge issue. We build & deploy by just copying the (uber)jar and restarting the systemd service. Quite simple but I like to keep up with some other approaches and we never know, when we have to do a desktop app or something.

I hate the old school way of writing Java more than any other language. I love writing in "modern" Java more than any other language.

Lombok, RxJava/Reactor where possible, and monads everywhere. It is beautiful and succinct, though I totally appreciate it may not always be easy to introduce on older frameworks or legacy projects.

Can you link an example of a codebase written in this modern-Java style? I've seen parts of it here and there, but I don't think I've ever seen all this used together.

Lombok is too much magic for me, record class and the annotation generators libraries are a bit less magic

>Lombok is too much magic for me

If an object is just data, then @Data is all you need. If an object crunches numbers, then @Service with @RequiredArgsConstructor if you don't prefer to @Autowired things individually.

Any other usage of Lombok is possibly indicative of a questionable application design imo

Try Kotlin. Unlike Scala, it's not really a new language, it's more like syntactic sugar.

Haven't used Lombox, RxJava is great, but it just feel like bandaids on a language that wasn't really designed for it.

There's no accounting for taste, but I'll take either Scala or Clojure on the JVM any day of the week. Scala's monads don't feel like a library feature, they feel baked into the language...because they are.

Lombok is indeed a band-aid that replaces IDE-autogenerated code, which in turn is a band-aid for language design choices on the one hand (e.g. equals and hashcode), and accepted Best Practices in Java world like setters/getters everywhere; for the latter, you can either do public final fields, just use public fields until you need an accessor method (java's refactorings are great), or on the other hand add language features like in C# and Scala where from a class consumer point of view, accessing a value or calling a setter/getter are the same.

That said, I did hear Java is getting value types soon, or something like that. A bit too little too late maybe, but welcome nevertheless.

If I had the choice I wouldn't use Java again; JVM is fine, but there's better languages for it than plain Java. Kotlin seems alright. Wouldn't use Scala again, that's a language for sadists.

> That said, I did hear Java is getting value types soon, or something like that.

Java has had records (the thing that's like Lombok) since Java 14.

What Java is soon getting is inline value types, i.e. datatypes that work like primitives (are pass-by-value; have no identity but rather structural equality; are freely copyable; can be held on the stack, or intrusively within a containing array; etc.)

Java designers chose the public method with the same name as the corresponding field policy as the preferred one (as per record’s design), this combined with the coming syntax for “copy the object but changing these fields” will make java quite good to use imo.

Scala definitely has its irritations but I’ve grown to accept it. It has enough cool features to justify its existence.

I’ve not used kotlin but people I respect say it’s great, maybe that’s better than Scala.

IME Kotlin is the worst of both worlds. It's like they took every cool one-liner example from Scala and said "see, you don't need a whole functional language to do that, we can just add this piece of syntax sugar and you can do the same thing while keeping that Java feel", but once you've done that a half-dozen times you end up with a language that's actually even more complicated since it doesn't have the underlying consistent core that Scala does.

I like Scala a lot more than I feel like I should. It’s weird to say that it’s a language that feels too academic while also being heavily used by enterprises. I used it a lot while working at BigCo and there were a lot of times that the language got in the way of getting things done due to the design. But it is really elegant once you understand it. It’s no Lisp, of course, but it feels somehow both pragmatic and academic in getting things done. And for writing Spark, it’s quite expressive.

Why use Lombok if you can use Groovy + CompileStatic? Does lombok do anything groovy can't do?

Scala is far ahead of its time. And has been since 2014.