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.
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.
I wouldn't go so far as to say that Reagent's model is perfect. Definitely pretty good, but we've had some issues that were somewhat non-obvious.
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).
Personally I'm a believer in Om, but am skeptical of the "global state is only for undoable actions" model it espouses. Personally, I think the application state should hold ALL state of an application... I think "undo" should be implemented using a separate mechanism.
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.
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."
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.
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:
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.
[+] [-] AlwaysBCoding|11 years ago|reply
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.
[+] [-] CompleteSkeptic|11 years ago|reply
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).
[+] [-] drcode|11 years ago|reply
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.
[+] [-] drcode|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] zubairq|11 years ago|reply
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...
[+] [-] dopamean|11 years ago|reply
[+] [-] presty|11 years ago|reply
there's a reorg going on, a github org has been created and development is restarting
previously, dev was happening at whoops' fork
[+] [-] erikcw|11 years ago|reply
https://github.com/reagent-project