Fork me on GitHub

I’ve just finished the 3 month development of a commercial product for a client. We used re-frame to build out the SPA (vs backbone.js on the previous version). The result was excellent and I would definitely recommend to clients to use re-frame in the future. I’m feeling confident enough in my cljs / frontend knowledge to approach om/next. I’ve read the docs and done the basic and intermediate tutorials. What’s not clear to me is what om/next offers that re-frame doesn’t, and why might one pick om over re-frame (or vice versa) for a project. Is anyone interested in sharing their opinion on this?


@stuartrexking : I had the same question a few weeks ago. I didn't find a satisfactory answer. I would love to know what you find. The one thing I can contribute is as follows: I believe om/next solves an additional problem -- whatever it is that Falcor / GraphQL solves -- it does something for transporting data between client/server in a synchronized and efficient manner.


@qqq I have heard that, but I can’t see it. on-sync does some reasonably nice synchronization stuff, but it’s an add on.


Om looks like a great framework, with a steeper learning curve than re-frame. Having worked with re-frame, the data flow is elegant and it’s clear what each step does. With Om I don’t get that (at least from the tutorials which might not be enough). I would love to hear from @mikethompson on this and why he built re-frame. It’s not clear in the readme, and I think it should be. What makes re-frame better (or better suited in certain scenarios) than the alternatives.


@stuartrexking When I read about OM (orig), back in 2014, I was really puzzled by the adulation. I felt it had some fundamental problems, and I felt they were really obvious. But ... I was just learning ClojureScript and I kept thinking I was missing something. I'm an older and pretty experienced programmer but I was doubting myself because more knowledgeable functional people seemed to love it. What am I missing? What am i missing? It was very confusing. As it turns out, I wasn't missing much .... we've subsequently seen wave after wave of refugees from OM (orig). I don't think it has stood the test of scale and time. Cursors are a terrible idea (in the large) and being forced to organise your data to mirror the component hierarchy is an equally terrible idea (in the large).. OM (orig) had a very OO design, and everything was all one big ball of twine. Event buses were used to synchronize state, which is an OO pattern I've used many times over the years, and not very functional. Just to be clear: there were a couple of important ideas in OM, for sure, and I'm very glad it existed. But overall it didn't work as a production base very well, IMO. But I'm sure there'd be some who would disagree - CircleCI seemed to do bigger systems in OM for example. Regarding OM next ... I don't know much. It seems "experimental". It is still alpha. I have heard some complaints about the learning curve. But then I've also heard that untangled makes it much easier. I've heard someone say it makes good sense if you are targeting Datomic. But my knowledge is shallow. I do know that having David Nolen's stamp of approval will take it a long way (just as it took OM orig a long way). I'd suggest asking in OM channel. What you want, i think, is to find people who have migrated from re-frame to (or visa versa). They'll know both systems well, and then be able to compare. I'm not that guy.


@mikethompson Thanks for a great response. Without having any om experience, other than reading the tutorials and reading all the docs, I think I sense what you sensed in 2014. To me it looks like the additional complexity doesn’t add any value, when compared to re-frame.


om and are not good at “idiot using a technology litmus paper test”. I’m being a standard coding monkey tried to use om back to 2014 and failed, tried reagent and was productive almost immediately. then the same thing happened when we hit the limit of building a reagent application without any consistent approach to state management - we migrated to re-frame and were productive almost immediately

stuartrexking06:02:16 could definitely take a tip from @mikethompson on how to write a readme.


I switched from to re-frame. For me it was just too hard to learn since documentation at the point was very minimal. Also it took lots of time to implement some simple http caching. There was this one thing (learning the framework from scratch to the actual implementation) that took me 3 weeks to achieve with and like 15 mins in reagent/re-frame, that made me to switch.


David is a great guy with great ideas, but almost everything that he does (except, probably, core.match) is not for average guys like me. good ideas & good design should be packaged appropriately so they can be consumed easily, imho, and re-frame does a great job in this area


I'm operating on a very big re-frame application currently. Wouldn't be possible to use due to the learning curve.


But these are just my thoughts. I didn't express any opinion regarding in general or anything else. Just tried to describe my experiences on actually learning a framework.


There's just so much stuff you need to learn when you try to learn Om Next, the query syntax being probably the hardest part. Then again, if you use Datomic, maybe it'll come naturally to you? shrug


are there any public stories about large production app written in


One of my biggest personal issues was that queries had to flow up to the root component.


But maybe i'll not continue about this here since this is a re-frame channel.


also not to give people interested in trying the wrong impression 🙂


Wow, you guys have a nice talk. For us: It's incredible to learn that what drives you to made this framework. Thanks.


I think the best part of is the query syntax for server communication, but then that is a big piece you need to implement yourself. We did and it has been worth it. But I think it will be even better for us to use this, except with re-frame on the client


it is simpler, way less possible mistakes to make, and that is important when you need to implement a lot of logic yourself, like tracking what rows+columns need to be synced with the db


re-frame question: I find myself wanting to use this function all over the place when registering subscriptions. Is there something i'm not getting?

(defn reg-sub-for-paths [k paths f]
   (fn [db _]
      (apply f (map (fn [path] @(ra/cursor db path)) paths))))))


(to avoid the subscription firing any time the app-state updates)


to answer my own question, that variant doesn't work well if the path takes a variable id