I agree 100% with this post. Reagent is the best UI library that I've ever worked with. It's powerful, just works, and it's easy to understand what's going on under the hood.<p>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.<p>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?<p>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.
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...<p>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.<p>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.<p>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."
Actually Om's undo is very powerful, my framework Coils allows playback of sessions, which is very useful for customer service to know how a customer uses a webapp:<p><a href="https://github.com/zubairq/coils" rel="nofollow">https://github.com/zubairq/coils</a><p>:and a demo here:<p><a href="http://connecttous.co/connecttous/connecttous.html?playback=true" rel="nofollow">http://connecttous.co/connecttous/connecttous.html?playback=...</a><p>:and here:<p><a href="http://connecttous.co/connecttous/connecttous.html?livedebug=true" rel="nofollow">http://connecttous.co/connecttous/connecttous.html?livedebug...</a>
I haven't had a piece of technology make me feel like more of an idiot than Om. I don't know what it is but I just don't get it. I've found Reagent to be more accessible.
fiy reagent is not "unmaintained" anymore<p>there's a reorg going on, a github org has been created and development is restarting<p>previously, dev was happening at whoops' fork