6 ms·

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?

okal 11y ago
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.
- bostonOU 11y ago
  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.
Frozenlock 11y ago
It was mostly the whole reify dance, which I never had to do in any other clojure/clojurescript project.
- jeremiep 11y ago
  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 :)
  - Frozenlock 11y ago
    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 ;-)
    - jeremiep 11y ago
      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.
- fendrak 11y ago
  I recommend using https://github.com/Prismatic/om-tools https://github.com/Prismatic/om-tools, if only for the defcomponent macro: https://github.com/Prismatic/om-tools#defcomponent https://github.com/Prismatic/om-tools#defcomponent This abstracts out all the reify stuff and makes for far cleaner component definitions.
MikeOfAu 11y ago
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 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.
- swannodette 11y ago
  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.
  - MikeOfAu 11y ago
    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.
glenjamin 11y ago
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.
- bostonOU 11y ago
  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.

okal 11y ago

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.

bostonOU 11y ago
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.

Frozenlock 11y ago

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

jeremiep 11y ago
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 :)
- Frozenlock 11y ago
  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 ;-)
  - jeremiep 11y ago
    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.
fendrak 11y ago
I recommend using https://github.com/Prismatic/om-tools https://github.com/Prismatic/om-tools, if only for the defcomponent macro: https://github.com/Prismatic/om-tools#defcomponent https://github.com/Prismatic/om-tools#defcomponent This abstracts out all the reify stuff and makes for far cleaner component definitions.

MikeOfAu 11y ago

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

swannodette 11y ago
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.
- MikeOfAu 11y ago
  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.

glenjamin 11y ago

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.

bostonOU 11y ago
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.