[drcode]

OK, as someone who is a believer in the Om philosophy, it behoves me, for the sake of a substantive debate, to give my best rebuttal to OP...

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

[CompleteSkeptic]

If any of my post sounded as if I was complaining about the lack of syntactic sugar, I apologize as that was not at all my intention. The best practices and syntactic ugliness didn't matter to us at all after the learning curve. We wrote some macros to solve the problem, and didn't have to think about it anymore. We used sablono as well, so the syntax was almost the same as that of Reagent.

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.

[drcode]

Hmmm... having a library like Om where the cursors function on a DAG actually sounds pretty useful... I'd love to see an implementation of this :-)

[CompleteSkeptic]

Yup! We were about to implement something like that, but we realized Reagent's model of having atoms store the state worked pretty well with javelin's FRP, and once you break down the state into atoms, the cursors aren't needed anymore.

[drcode]

Looks like David implemented this on Saturday (reference cursors)