Hacker News Reader

Comment by bostonOU | Hacker News Reader

Can you explain why Om hurts your brain? I've heard other people say similar things, but I've never quite understood why. Is it cursors? Local component state?

View on HN

OM components are complex. There are global transaction/message channels, component local state, an OO backpane, lifecycle functions, functional zippers, hierarchy organised data, etc. I can't understand how anyone could claim it to be simple.

Look at this example code, apparently held in such high regard that it is referenced off the front page of OM: https://github.com/swannodette/om-sync To me that is a ghastly, inexcusably complected hairball.

Don't get me wrong. I really like clojurescript. I program in it daily, on purpose. It is just that I'm shocked at the level of devotion and adulation for OM when there are really lovely alternatives like Reagent and Rum.

Some inaccuracies here about Om. There are no message channels. There are no functional zippers. Component local state and lifecycle are critical React integration points. Hierarchy organized data is not required - people have succeeded at integrating DataScript. om-sync isn't even an official thing, just got tired of people asking me about a basic example :)

If you don't like Om, that's really OK. The real goal of Om was always to inspire people to consider and research alternatives to traditional client-side MVC. 16 months in I would say with the large number of excellent alternatives, Om very much succeeded.

I hope Om Next accomplishes the same broad goal and convinces people to seriously consider the big ideas behind Relay/GraphQL, JSONGraph/Falcor, and Datomic.

No zippers? Why then does the official OM docs say "Cursors are conceptually related to functional lenses and zippers". Remember this thread relates to how simple or easy OM is to grok.

And no message channels? Why then does the intermediate tutorial plunge straight into the use of core.async?

I have no problem with OM being considered a grand experiment. I wouldn't use it but it has been an interesting idea generator. Please remember context here - I was responding to someone who claims astonishment that OM could be considered difficult to understand.

But, in terms of grand experiments, let's remember that Reagent came out at exactly the same time as OM. And Hoplon lead the way on Reative (FRP) long before either. So, having lived through it, I'd feel very uncomfortable with any overreaching claims about OM succeeding in inspiring all the others into the alternative MVC holy land. The others were there already.

I also feel that Om is very complex. I'm sure I've spent over 20 hours trying to wrap my head around it but didn't manage to do anything.

From the people that know it well, they all love it. But I don't seem to have the required knowledge to understand it. I feel somehow dumb by that. The docs aren't good also.

After that, I've tried reagent for 30 minutes and ended up with a lot of progress and I'm currently writing my first cljs small app. Everything seems to work and it's like clojure.

You have an atom and just have to write views in a hiccup style, everything magically works.

Maybe I will try Om later and get it, but it's not simple. I've been able to wrap my head around a lot of concepts with easy in my life, but Om felt too much.

"From the people that know it well, they all love it. But I don't seem to have the required knowledge to understand it. I feel somehow dumb by that."

When I get this feeling, it's often because I haven't yet experienced the problems the new thing is trying to solve. Is it possible Om is an attempt to solve problems you haven't encountered?

I have no personal experience with Clojurescript (love Clojure, though), so this is just a generic comment.

I'm learning clojurescript in addition to (eventually) learning Om. I feel like Om provides you a lower level of abstraction than Reagent which is good for building some complicated web apps. However, as a CLJS beginner, Reagent and the re-frame framework have been easy to dive into.

Pairing with someone who's built a few Om apps should get you up to speed in no more than 45 minutes. I've done it a few times now, and it just takes a few examples, building some components, and composing them together.

I don't know anyone with interest in Om/clojure though :(

I think it's mostly a matter of personal preference. There are multiple React interfaces in ClojureScript: Om, Reagent, Rum, Quiescent being the most popular. Pick whichever you like.

I looked at Om, found it too verbose, and switched to Reagent. I then found it too limiting, so I ended up using Rum, which I think is the most flexible and the most minimalistic. I think it's great that we have the choice and that we can cross-polinate ideas between various libraries.

I use it every day, but there's always some aspect of its behaviour that it turns out I didn't understand the first time round. Perhaps that's because I jumped into the project with only a very rudimentary understanding of Om, just enough to complete a certain ticket. I've since then spent a lot of time going through the docs, but it just conceptually doesn't sit well with my brain. Sorry I can't give a more useful answer. Reagent on the other hand, which I haven't used in production, just "feels" better every time I play with it.

The thing that helped my understanding most was a recent project where I got to work with React directly. Also, reading the source.

So yes, it's mostly because I'm a little lazy, but Reagent doesn't seem to punish me for that same laziness. 😆

EDIT: More details.

While not a specific answer, "feels" is a valid response IMO. Like mentioned elsewhere, using reify seems to throw people off, which falls in to the "feels" category I think.

I think part of the reason some people feel this way about Om is that it was built as an experiment - specifically an experiment about handling immutable state in React.

I find that Om has very strong opinions about doing state the clojure way, but is a very thin wrapper around the rest of React's API - which leads to a feeling of inconsistency.

Some of the stuff David's suggested will be part of "Om next" I think will address this.

The inconsistency part makes sense, I guess I just never thought it was a big deal. If you're going to use WillMount, it's either going to be with reify (Om) or meta (Reagent). Doesn't seem like an important distinction to me, but obviously it is to some people. And that's totally legitimate.

It was mostly the whole reify dance, which I never had to do in any other clojure/clojurescript project.

I recommend using https://github.com/Prismatic/om-tools, if only for the defcomponent macro: https://github.com/Prismatic/om-tools#defcomponent

This abstracts out all the reify stuff and makes for far cleaner component definitions.

reify is usually a low-level construct in Clojure. A lot of libraries use it under the hood, I wouldn't be surprised if you use a few of them :)

Probably, but it still left me feeling a little alienated.

Not to take anything from Om tho, people using it seem to enjoy it a lot! I guess I'm just less smart ;-)

I wouldn't say less smart, it took me some time to get used to reify before feeling comfortable using it too. Think anonymous classes in Java for example, its almost the same thing.

Reply on news.ycombinator.com