[Cshelton]

Ok I see now. I think both methods have a place going into the future.

What I've understood from Relay/Falcore/etc. is those technologies are great for something like Facebook or Netflix, hence why they made the frameworks, but for many other cloud/web apps, it may not make sense. A single atom app state works really well. Is that along the lines of the right thinking? I'm using React+redux along with websockets and haven't had any problems with large state trees, but the whole state can be sent to and from the server very fast as it's not too big.

I'm sure Elm will have something comparable to Om Next/Relay/falcore as well then, to solve those use cases.

[jlongster]

I don't think it's that's simple. It's not that it works better for hugely complex apps. It just works better for certain kinds of apps, even if they are small. The project I'm working on is small, but Om Next is far better suited to it (the complexity of using Redux+Redux/etc on it would be far greater).

The question is, are the majority of apps better suited for a tree-based state or a queryable graph? I'm not sure, but it's at least even.

I've heard Elm is working on something similar, so I wouldn't be surprised if that happens.

[slorber]

Is the same data displayed into multiple branches of the tree? :)

[jlongster]

You mean the component tree? Sure, it can mixed in whatever way the component tree wants it.