Thanks for the detailed response, Sean. Interesting and good points. I've seen Peters notes and my initial thoughts were that half of the "Bad" points can be easily solved using om-tools and the other half by adhering to a strict separation between domain state (the what - stuff you'd store in a database) and transient state (the how - stuff that tells your app how to display the domain state), storing the former in app state and the latter in component local state. From what I've read, this is what Facebook do with their Flux-based code too.
There's no doubt that Om is very OOP (perhaps even a bit uncomfortably so, for Clojure), so I guess perhaps at the end of the day it comes down to how much OOP you're happy with allowing. For me, I don't mind it for the GUI code and my actual logic is very functional in style. Reagent definitely appears to be more functional style, though, which is definitely nice. I haven't tried Reagent myself, which is why I'm interested in hearing peoples experiences - especially if they've used both Om and Reagent. Maybe I can find some time to play around with it soon. On 9 September 2014 19:18, Sean Corfield <[email protected]> wrote: > Switching the subject, but keeping the thread. Apologies to those whose > email readers may get confused... :) > > On Sep 9, 2014, at 9:37 AM, Paul Butcher <[email protected]> wrote: > > On 9 September 2014 at 08:52:01, Daniel Kersten ([email protected]) > wrote: > > I'm just trying to get a better understanding of what pros and cons Om and > Reagent have and why Reagent is a better fit for your specific use case. > I've seen a few people switching lately so I'm interested in hearing > people's thoughts. > > I've written a couple of production systems using Reagent. I've not > written any with Om, but have played with it quite a bit while evaluating > it. > > The reason why I decided to go with Reagent is code readability - I find > it much easier to read. This is particularly relevant as many of the > developers working on the code are new to Clojure/ClojureScript and my view > was that they would find it much easier to understand Reagent than Om. > > > This is essentially why we switched too. Learning Om was extremely > valuable in understanding the React.js "model" of thinking but it felt very > "OOP" in style and, the bigger our app got, the more that bothered me, > along with the boilerplate of `reify` and `om/IWhatever` and then the > method definitions. It was still Clojure but it was starting to feel like > Java at times, especially with the very explicit "constructor" and local > state idioms - and the various state mutation functions. > > The component signatures also felt a bit rigid, always passing some state, > the React node, and the optional `opts` map, so component dependencies had > to be shoehorned into that structure. There were also times when it became > cumbersome to communicate between components (I know David is aware of this > and working on improvements). Om is very structured and quite opinionated > about "how to write your app" and seems to "strongly encourage" use of > channels and core.async when passing data or a simple callback might be a > simpler approach, if it was possible (and it might be - I just felt I was > fighting with Om sometimes trying to achieve some of this). > > The DOM stuff was also a bit frustrating so I'd started to move over to > using Sablono to get that familiar feeling from Hiccup, but as you can see > in my early Om/Sente example code, I was mixing and matching the `(dom/tag > ...)` and `(html [:tag ...])` styles from both libraries and that felt a > bit clumsy (a mix of Sablono and `om/build` in `secured-application` seemed > inconsistent - whereas pure `dom/div` / `om/build` in `application` felt > more consistent but a bit ugly): > > > https://github.com/seancorfield/om-sente/blob/master/src/cljs/om_sente/core.cljs#L322 > > Of course that's all very subjective, but Reagent's Hiccup-style > (component) "functions return data structures" approach seemed more > consistent, more streamlined / simpler, and more flexible since it was > "just functions" (and closures over state) so you could pass whatever > arguments you wanted / needed. That meant one library (Reagent) instead of > two (Om + Sablono) so less worry about version incompatibilities etc. On > the downside for Reagent, there's a lot more "magic" in terms of how > rendering is triggered based on Reagent's "magic atom" and by simplifying > the main line use case (rendering, and using closures for initialization), > you have the added complexity of wrapping components in metadata to hook > into the other React.js lifecycle methods. It's also less widely used so > there are fewer blog posts and articles about it and far fewer folks on IRC > to ask questions of and bounce ideas off. > > At a recent San Francisco ClojureScript meetup, some folks recounted their > experiences building production apps with Om and various other frameworks > which I think makes interesting reading (I couldn't attend unfortunately so > I was very grateful that Peter took detailed notes!): > > http://pchristensen.com/blog/articles/sfcljs-august-meetup-om/ > > There are definitely things to love about Om. It's well-documented and > there are plenty of examples and blog posts about it. There's a growing > community of libraries and tooling being built up around it too. The > structure and organization means components are fairly homogeneous in > approach which means consistency as well as a fairly straightforward > mapping between React.js and your cljs code. Cursors are great! (so much so > that I submitted a PR to Reagent to add cursor-like functionality) > > And finally, if it wasn't for Om, we almost certainly wouldn't be > embarking on our ClojureScript journey for (internal) applications at World > Singles: everything else we'd looked at before seemed to be a heap of JS > interop, built on top of JS frameworks, which hadn't been enough to tempt > us away from pure JS front ends... > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "Perfection is the enemy of the good." > -- Gustave Flaubert, French realist novelist (1821-1880) > > > > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
