I was able to teach a data scientist on our team how to build UI components in Reagent in less than 24 hours to the point that he was able to build his own visualizations for his data analysis with minimal guidance, that's how intuitive it is.
Compare that with Om which I've tried for about a month to grok and still can't get a handle on it. The only advantage that Om gives you over Reagent that I can see is global undo out of the box, but it's at the cost of significant added complexity. And if that's what you were really after you could just build one global state atom in Reagent to give you global undo without all the added complexity of Om. What am I missing here?
I think Reagent's model is the perfect blend of ClojureScript + React. The only shortcomings are that it's not actively maintained and I wish there was a more robust library of helper methods baked in, but those are easy tradeoffs to make for something so simple and powerful.
If you're worried about it being maintained, there was actually a great discussion of this post on the clojure subreddit (https://www.reddit.com/r/Clojure/comments/2jq0cu/om_no_troub...) where others talk about Reagent having a community-maintained fork with new features.
Out of curiousity though, what kind of helper methods would you be looking for? I found it pretty comprehensive on its own (though I do have some utility methods for some niche uses involving hierarchical atoms).
The primary selling point (for me at least) is that the cursor mechanics greatly simplify inter-component communication for react components. If you're not seeing those benefits, then the architecture of your app must differ greatly from my own- From this limited information, I can't really explain the difference in impressions in any more detail.
First of all, I cannot stress enough that Om is very much an ALPHA project. You cannot possibly visit the Om github page and not realize this. It says clearly "Om is still in the design phase so enhancements are low priority" so you should expect that there's zero hand holding for newbs for this project right now. Om is HARD right now, because the author is focusing on clean design, not on optimizing a beginner's learning curve. I highly respect the author for taking this position.
Because of this, very basic and obvious things are missing in Om (such as a macro to add syntactic sugar to the "reify" command, for example) and this is because the author feels that there is still a lot of uncertainty on "best practices" in client side development and that it is therefore premature to decide what sort of syntactic sugar is best. Most likely, this is the correct choice.
Additionally, by admitting you're trying to put mutable state into the application state object (well, at least it sounds like you're admitting this... correct me if I misread your post) you're really placing pretty unrealistic demands on the Om library- This is comparable to a person going to an AA meeting and saying "I want you guys to keep me sober on 6 days a week, but on Wednesdays I really like visiting my biker friends at 'Sloshed Biker Bobs' and will drink it up to the max on just that one day... but if you can't keep me sober on the the other 6 days I'll just assume AA is useless."
The biggest problems that we faced with Om were how normal Clojure-y things just didn't work with it, and how the app state had to be kept in a tree instead of a DAG (mostly the latter), which created issues with consistency, performance, or both.
> trying to put mutating state into the application state object
How you're supposed to use Om is put all the mutable state into a global atom. I didn't mean putting reference types in the global atom or anything horrible like that, but the problems with cursors being pointers still exist.
https://github.com/zubairq/coils
:and a demo here:
http://connecttous.co/connecttous/connecttous.html?playback=...
:and here:
http://connecttous.co/connecttous/connecttous.html?livedebug...
there's a reorg going on, a github org has been created and development is restarting
previously, dev was happening at whoops' fork