The om-next documentation states that de-coupling global app-state using cursors is problematic, however, I never experienced much problems with this. Is there a doc somewhere that compares cursors with om-next's approach?

To summarize, cursors seem fine to me, and I don't see why I would need the complexity that om-next brings, what am I missing?

@chrisblom For me the biggest issue was the documentation for om next had a lot of gaps. After getting into it it feels like there’s a few clean separations of om next. I find it to be a better alternative to the new React stack of GraphQL/Falcor, Relay, Redux. 1. I’m using it because I need an app that is more dynamic where the views can be controlled by the query. 2. Removing the async work helps to keep my risky code isolated. 3. The read, mutate, transact help to keep state mutations in sync between multiple clients/servers and with offline support.