

Trouble in Paradise with ClojureScript and React.js - CompleteSkeptic
https://diogo149.github.io/2014/10/19/om-no/

======
AlwaysBCoding
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.

~~~
CompleteSkeptic
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...](https://www.reddit.com/r/Clojure/comments/2jq0cu/om_no_trouble_in_paradise_with_clojurescript_and/))
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
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)

------
zubairq
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:

[https://github.com/zubairq/coils](https://github.com/zubairq/coils)

:and a demo here:

[http://connecttous.co/connecttous/connecttous.html?playback=...](http://connecttous.co/connecttous/connecttous.html?playback=true)

:and here:

[http://connecttous.co/connecttous/connecttous.html?livedebug...](http://connecttous.co/connecttous/connecttous.html?livedebug=true)

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

------
presty
fiy reagent is not "unmaintained" anymore

there's a reorg going on, a github org has been created and development is
restarting

previously, dev was happening at whoops' fork

~~~
erikcw
Just thought I'd post the link to save readers a search...

[https://github.com/reagent-project](https://github.com/reagent-project)

