

A Conceptual Look at Om (ClojureScript for React.js) - lkrubner
http://josf.info/blog/2014/09/18/first-ompressions-a-conceptual-look-at-om/

======
davedx
I've recently worked on back porting the "cursors" feature of Om to our React
project using Facebook's immutable-js library. Although I did have some
success (I got a basic POC working inside our app), the work to do a complete
port of our project to this way of doing things was decided to be too much
effort for the benefits it would bring.

I am still, however, a big fan of the immutable/Om way of doing things with
React, and it will be the way I build future React projects from the ground
up.

Some feedback on the article itself:

"For an animation, like moving a <div> from left to right, the IRenderState
function might be called several times a second. Sometimes it is better to
think of your app like a movie (a cartoon, I guess) rather than a static set
of objects sitting around waiting for events to happen. And if you are
thinking: “that must be horribly slow”…​ well, it isn’t, thanks to React’s
virtual DOM that efficiently projects changes out into the real DOM."

If you're re-rendering a div in different places using Om/React in order to
animate it, I would say you're probably doing it wrong. You should do one re-
render to apply a new CSS transition class.

Also, lots of re-rendering on desktop Chrome is, usually, quite fast because
of V8 and desktop CPU's... try doing this on mobile, or (in our case) a DTV
set-top-box, and you'll quickly run into performance issues. Not every
JavaScript engine/platform is fast enough to pull off the naive "re-render
everything" approach in React. That's why they included shouldComponentUpdate,
and why David Nolen went to such effort to facilitate cheap
shouldComponentUpdate checks in Om.

Of course, YMMV, don't optimize prematurely, but don't also assume "re-render
everything and the virtual DOM will always make it fast enough".

~~~
dustingetz
GitHub.com/dustingetz/react-cursor

It supports o(1) shouldComponentUpdate

My hn comment history has some discussion about it

I'm on my phone now but if you email me I can give more info. I've used react-
cursor in two enterprise grade apps in regulated industries and couldn't
imagine using react without cursors (believe me I tried)

~~~
davedx
Looks nice! I've emailed you.

------
vitno
Om is really cool and David Nolen is an awesome member of the Clojure
community. However, I've played around with Om and found it to be a rather
complex tool. I think it would be perfect for a high performance web app where
I need to control everything - but thats not what I generally need.

I've enjoyed working with Reagent, which is another react clojurescript
interface. It sacrifices some very minor functionality for an extreme decrease
in complexity. It's actually enjoyable to make a UI with it.

~~~
AlwaysBCoding
+1 for Reagent. Best UI library that I've ever used. Om is really confusing to
me and requires too much configuration to make it usable. Reagent works out of
the box and just makes so much sense. It never feels like you're using a
framework, it just feels like using a tool to abstract away the complexity of
rendering from your UI logic. It's really enjoyable to use. Then again it
hasn't been updated in six months so there's that...

~~~
smrtinsert
I think someone linked a fork in the issues thats being maintained... prs and
all.

------
pbiggar
If you're interested in seeing a complete in-production Om app, check out the
CircleCI frontend: http s://github.com/circleci/frontend

~~~
KurtMueller
Got any other examples? I like seeing what's being made in Om and want to
eventually use it in my own apps.

~~~
ffreire
There are plenty[0] of examples on the github page for Om.

[0]: [https://github.com/swannodette/om#applications-built-with-
om](https://github.com/swannodette/om#applications-built-with-om)

------
bmh100
A very interesting point was the statement "...renders the MVC terminology
obsolete. Not that we don’t have models, views and controllers anymore; it’s
just that the layering of the three is no longer relevant."

Could someone please expand on this statement? If the purpose of the MVC
separation was a separation of concerns and organization, what is the impact
of their layering no longer being relevant?

~~~
dj-wonk
I wouldn't choose the same words as the author. Perhaps I would say this
instead: "... it’s just that the layering of the three is no longer _pre-
ordained_ by the framework."

Here's my take. Om's "application state" (only data) corresponds to the data
part of the model ("M") in most MVC frameworks. In Om, just like ClojureScript
or Clojure, you use functions, organized however you like, to work with data.
This means that the "action-oriented" part of a traditional MVC model (e.g.
methods in OO) are not necessarily grouped with the model data. Perhaps this
is what the author is getting at: you can "layer" (organize) your functions
into whatever namespaces you like.

In in my recent experience building Om apps, I've found that organization
matters. As an Om app grows in size, it is natural (and important) to find
ways of organizing that help. Om does not impose any particular organization
scheme. I personally find ClojureScript namespaces to be very easy to work
with; I simply split up a codebase as files become larger and harder to
summarize.

~~~
skillet-thief
(Author here)

"... it’s just that the layering of the three is no longer pre-ordained by the
framework."

That is pretty close to what I think. And I don't have any great certainty
about any of this. I'm not going to go around saying "MVC is dead!"

What I observe with Om is that Om works well because it determines a flow of
data, and the tools that we have to influence that flow of data, which could
be identified with M, V or C, don't need to have any kind of formal
separation, as opposed to a framework where you would have Model objects,
Controller objects and View objects. It seems to me that Om and React have
shifted the metaphor a little bit, and that the MVC metaphor isn't the best
one to describe what is going on.

------
linguafranca
It's nice to see the Clojure/ClojureScript community growing. But the fact
remains that these tools still don't enjoy the maturity of their more
mainstream counterparts.

So if you use any ClojureScript libraries in production, expect to run into
strange issues and submit bug reports that are not responded to for months on
end. Nothing against their authors, it's just the nature of writing niche
tools.

~~~
swannodette
This is not my experience. Doing JavaScript for years I mostly leaned on
jQuery & Underscore.js and more recently React. ClojureScript has all the
functionality of Underscore.js and a whole lot more, Google Closure I honestly
find just as usable as jQuery for the cross browser bits, and finally there
are several React bindings like Om. And I do a pretty darn good job of
maintaining Om :)

~~~
sgrove
There are still some huge hurdles to overcome for working on large projects &
medium-size teams with designers. Nothing insurmountable, but a lot of polish
that still needs to be put into (re-)usable infrastructure, tooling, and
polish.

All that said, once devs are up to speed, and designers have a modicum of
tooling, it's the best system I've used so far.

