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)
signature.asc
Description: Message signed with OpenPGP using GPGMail
