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
Recently I've been working with cljfx for developing a JavaFX app with clojure. cljfx does a great job of creating a re-frame like development experience for JavaFX.
Happy to see new developments here, though FWIW, I've mostly had a good time with JavaFX, especially in Clojure, where there's a neat Reagent-style (a React wrapper) library called cljfx[0].
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.
From the outside it looks like an understandable shift away from desktop applications (the devs and money isn't there). I made an desktop app used Clojure + CLJFX and I got a ~25MB JAR. It then balloons to ~65MB jlinked packages. I ended up just releasing the JAR and telling people to install a Java 11 runtime (though I may revisit this at some point)
I think what it boils down to is that b/c of Java's reflections you simply can't get rid of unused code/dependencies and things constantly bloat very fast. Small apps that should be 2MB are >20MB and are "un-emailable". On the server side this is a nonissue but to me it makes the ecosystem unsuitable for user-facing applications. There is a reason you don't see people making lil JVM desktop applications anymore.
I love writing Clojure, writing the app with CLJFX was fantastic and fun but if I wanna make a quick app to crunch some data and make some plots I'm now very hesitant to reach for the JVM. I'm hoping with GraalVM the situation will change (b/c I don't think it supports reflections/RTTI and it can prune dead code/dependencies) but last I checked it didn't work with JavaFX.
PS: I manually pruned the dependencies in `deps.edn` with `:exclusions` which helped a lot. Otherwise the app is in the ~200MB range.. But it's a manual process and tedious. The toolchains can't guarantee which code is unused.
https://github.com/geokon-gh/corascope/blob/master/deps.edn
Nice, I remember the initial blogpost but haven't followed progress. There's definitely friction working with JavaFX but you get so much for free. I don't have the aversion many Clojurists seem to have to accepting the bounties of the Java ecosystem, and I've been around long enough to be slightly leery of pure Clojure libraries that fail to reach critical mass (which, if we're totally honest, is almost all of them given enough time).
Sadly, I can't share any code, but here's my basic observations:
First, calling a standard Java object from Clojure is extremely painless. It's a bit more complex if you're dealing with listeners, but in general terms a java object is a java object without very much getting in the way. This means that all of your favourite GUI libraries are usable without modification.
Second, as Carl pointed out, Clojure does have state, it's just tightly controlled. So tightly controlled that multi-threaded programming is much easier. There's some things that I'd like on top of what it does, but it's very powerful and useful.
Thirdly, I'm not denying that thinking functionally takes a while, but as you develop the skill, it's amazing how many things actually look pretty stateless. I've met actuaries who use F# for all of their calculations. Equally, converting game state to a 3d scene graph is a pretty stateless process (although I've yet to meet anyone who's actually getting paid to do functional game programming).
Hope that is interesting. Will be glad to share more.
Clojure's a decent choice for writing a cross-platform UI application, using Swing. Java+Swing sucks, but Clojure+Swing works pretty well. I wrote a dependency graph library, dgraph, which significantly reduces the amount of boilerplate required to keep UI state in sync.
If you're interested in desktop alternatives for clojure, check out https://github.com/phronmophobic/membrane. It's different from javafx in that all the event handling code is pure clojure. For graphics, it uses skia, https://skia.org/.
I have looked at clojure for doing this somewhat recently (about 8-10 months ago) and the main issue I ran into was lack of bindings to some of the more necessary APIs for doing it these days (SDL, OpenGL, etc.). Some of them existed but were very badly documented/maintained which put me off of it a bit, but I do think that there are some definite things that could be gained with using Clojure at least (Of course you can use the JVM bindings directly, but that was starting to look very ugly as I played with doing so).
Clojure is a language, it is not necessarily bound to the JVM (although the common implementation is the one using the JVM). Like CPython to Python.
The JVM also brings with it the entire JVM ecosystem which makes clojure very practical.
Finally, there is actually an implementation of clojure for the browser (clojurescript) - which is a better idea than anything I've seen on the front-end (react-redux is OK, but clojurescript wrappers to react are just awesome). There is also an implementation for the CLR.
Clojure runs everywhere, it has a rich ecosystem since it utilizes good hosts (JVM, CLR, js engines (with google compiler optimizations)). It is, IMO, the most practical lisp out there.
Doesn't feel like a waste ;) The time spent investigating different GUIs in Clojure or integrating languages with better GUIs with Clojure feels does like a waste. I eventually settled on plain ol Swing but JavaFX looks quite nice.
clojure.spec was a nice step up to natively dealing with data 'shapes', I'm hoping the datify/nav protocols will be a step up to what I'm doing as well. It's basically a generalised browser over data with different print representations, collection handling, publishing, muxing, etc. The REBL will hopefully raise consciousness of just how abysmal the representation and navigation of the web is today.
Ha, I've used Clojure, see my thoughts above in the other thread.
By the way, I love Java, love Kotlin even more. Don't bring the JVM and other languages down to Clojure's level just because Clojure is clutching onto the JVM's coattails.
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
reply