[venantius]

There are a few weird conflations in this article that I think could use a bit of cleaning up. Why is om/next being compared to Falcor and Relay? Om in general is a very React-oriented story; why not compare how working with the two feels like?

It also feels like the author is primarily interested in client-side ClojureScript, in which case the Leiningen start-up time should really only be a problem once per...day? week? I re-start my Clojure(Script) REPL process only when I change underlying dependencies, which isn't frequent enough for it to be a major issue.

The biggest issue for me that I agree with is the immature tooling thing, but that's been getting a lot better since I also blogged about being frustrated with ClojureScript (relevant link: blog.venanti.us/clojurescript-blues/). Vim and the CLJS REPL now work well together, and I've been really impressed by the direction and velocity of Figwheel as a project.

[jaredly]

1) I see om/next attacking the same problems as falcor and relay, and david nolen makes reference to both of them (as sources of inspiration) in the talks he's given.

2) it may only hurt once a day/week once you have an established flow going, but when trying to figure things out & start things up, you restart a lot more than that. hence the barrier to entry

[venantius]

1. Going to look at the recent state of Om/next docs, I see that you're right. I don't think the earlier iterations of the project had quite the same focus but it's clearly been made a higher priority.

2. I think the barrier to starting a new project is unreasonably high, yes, and requires a highly inconvenient amount of configuration familiarity. Unfortunately the gap between just running the ClojureScript compiler on a single namespace file and actually configuring a viable project and build pipeline in Leiningen is quite large and really requires a concerted effort to overcome (or, to have someone nearby who's willing and able to show you what you're doing wrong).

[straws]

om.next lifts some great ideas out of Relay and Falcor. All three libraries share the assumption that components should describe the data they want, in the shape that they want it in. A querying layer is then responsible for for maintaining a local cache of the data, fetching it from the server when it's not available in the cache, and updating the components that are subscribed that data when it changes. This leads to some really impressive performance optimizations (only parts of the page that depend on new data need to be updated) and some very impressive server-side caching characteristics (om.next can use HTTP for caching because the data is normalized).