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

yes, JavaFX that cljfx wraps runs on the JVM

@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?

hehe exactly

maybe react, not sure 😄

specifically, react with hooks

I meant clojure libs 🙂

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

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?

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?

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

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

@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 🤷

@vlaaad aah I see 😊

@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.

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: https://www.reddit.com/r/Clojure/comments/aaydvy/review_request_for_cljfx_library_that_tries_to/