Om.next shows it's strength when you're working on a complex application 5k+ lines of code. A core abstractions of om.next (and graphQL) is to express data dependencies of your react classes in a query language (e.g. component X depends on data title, author, created, updated), then the logic around how to fetch data, refresh data, cache data or access cached data, update data, deduplicate data when it's needed in many places, optimistically update client-side data and wait for server-side data to synchronize is all disentangled from the logic on rendering complete data, missing data, data being loaded, reacting to user events, etc. In a smaller code base expressing these data dependencies would just seem tedious (writing graphQL or query expressions), but it pays up big time in larger applications.

I absolutely agree that larger apps are complicated, and that Om has thoughtful solutions to those problems, at the right level of abstraction. But I found it an absolute _pain_ to get going, and at every step it presented me with so many different primitives I felt lost.

If I had to compare it to any other tool, it'd be git. I love git. I use git every day. Do I understand the underlying mental model of git, or the 348 different git commands? Hell no.

Yes, I think those are all valid points/weaknesses. While I don't personal struggle with understanding the internals of git or om.next the learning curve is no joke. The community is aware of this, but it's still alpha software they're working on it. I actually think of om.next more like a library than a web framework. As a library it has many degrees of freedom in how it can be composed and i imagine the author prioritized flexibility/generality over concreteness, and a lot of work is still left up to the user in filling in the blanks of a full fledge web app, untangled (https://untangled-web.github.io/untangled/) is one project tries to fill in all the missing gaps and expose a framework API, much better documentation, more concrete than om.next.

I'd have to agree. Reagent was able to expose the beauty of the concept to me more clearly than Om. When I approached Om, I found it to be on a completely different level with regards to things to understand and absorb.

Having said that, I'm also pretty sure that Om yields bigger payoffs further down the road as far as I can tell.

What about re-frame is "a mess"? Pretty tiny API surface, solely aimed at forcing the best practices of unidirectional data flow / single source of truth. Have you ever looked at what the same thing entails in JavaScript, ie Redux?

I'd be happy to concede that my real-life experience of re-frame isn't representative, if someone were to show me an example of best practise. My main worry working on real apps has been that it's very hard to layer subscribe/dispatch in a way that allows for modular components, while at the same time separating out component instance state and app state.

Beyond that, the new reg-effect-fx system isn't particularly mature, individual fx aren't extensible, e.g. being able to extend http-fx to cancel or debounce requests.

I don't _hate_ it, I'm building apps in it. I just think there's a lot of overhead above Reagent that I have yet to see pay off, and the idea that it _forces_ best practises is wrong. It's like an MVC system that lets you put (_encourages_ you to, if you read the docs) controller code anywhere.

Knowing where to use `subscribe` (vs pure components) is an art and something that gets easier/clearer as you understand the app better. I'm happy to take responsibility for that aspect of the architecture though; the library's role is to provide the operations and patterns I might want. And if further generalizable patterns evolve, those can be turned into a higher level library.

Check out Rum: https://github.com/tonsky/rum

Have you looked at the Untangled framework? It seems to be exactly what you're looking for. https://untangled-web.github.io/untangled/

we're using untangled framework in production, I can't say enough good things about it.

Ta, I'd seen the name, but not looked at it in depth.

Very well put. I think this is an extremely insightful summary of the state of ClojureScript for the web today. I feel I'm still waiting for another leap forward.