Fork me on GitHub

Gratitude for Cider (need I say more?) and Biff (I’m finally easily getting apps deployed that I’ve wanted) and for all the awesome help I get from many wonderful Clojurians!

gratitude 13
cider 5

Thanks to @vlaaad for! I started to use it for yet another in-process Clojure dev tool and enjoy it a lot gratitude

gratitude 7
😊 1
Tema Nomad10:11:31

am I right cljfx is for system programming, not for web?


yes, JavaFX that cljfx wraps runs on the JVM

Tema Nomad12:11:18

@vlaaad just curious you mention "Unlike reagent" and "Unlike re-frame" issues of that libs in the readme of cljfx Do you know some alternative where is no such issues?


Do you mean are there web frameworks that are “like reagent and re-frame”, but without the mentioned downsides?

Tema Nomad12:11:48

hehe exactly


maybe react, not sure 😄


specifically, react with hooks

Tema Nomad12:11:32

I meant clojure libs 🙂

Tema Nomad12:11:01

or do you mean to use react w/o wrappers like reagent in cljs ?


hm, maybe I saw some minimal react wrappers that leverage hooks, but I don’t remember any of the top of my head

Tema Nomad12:11:47

Can you please describe this sentence about "re-frame" downside? > and subscriptions work on referentially transparent values instead of ever-changing atoms. What do you mean here?

Daniel Gerson12:11:34

I actually find this line of enquiry interesting, thanks @U04BRV8JQKE & thanks @vlaaad for making the library 🙌. It's not obvious to me the benefit of maps vs hiccup. Is this also purely aesthetic choice or have you found an efficiency benefit traversing the data etc?

👍 1

subscriptions work on values, so you can save your context in the REPL and query it during the debug session, without having to worry that your app state might change and affect outputs of your subscriptions


and app state might change in the running up just while it’s running, e.g. it might pull the server periodically and update the state with new data from server, etc


Regarding maps vs hiccup, the feature of hiccup is that after an optional attrs map in a hiccup vector you might have 0 or more hiccup elements that are semantically “children”, and that translates eventually to nested html tags, so there is straightforward transformation from hiccup children to html tags. There is no such thing in JavaFX, because not every object might have children. There is no concept of “children” that can be applied to e.g. labels, stage, scene. My first attempts at making cljfx actually used hiccup, but eventually I had to get rid of that because I had to constantly come up with how to treat “children” for types that don’t have any children. This was pure accidental complexity caused by hiccup DSL

👍 1
Tema Nomad13:11:25

Why do you speak about html library in case of using system programming lib?

Daniel Gerson13:11:00

@vlaaad Thanks for the explanation. I guess therefore maps make for cleaner code from the library maintainer's point of view. I guess from the user's view it's an empirical question of whether most use cases have children (requiring :children) which one is less verbose. Thanks again for taking the time to answer.


@U04BRV8JQKE I explained why hiccup makes sense for react/html, and why it doesn’t make sense for cljfx/javafx 🤷


@U03B2SRNYTY maps instead of hiccups is not about maintenance though, it’s about making it easier for the developer. You don’t need to remember implied rules e.g. that :v-box might have many children that are cljfx components, but :label can only have one child that is a string.

👍 1

If you are curious, there is a discussion I had on reddit (the top comment) back when I was developing cljfx that is about hiccup vs maps:

👀 1