[jlongster]

Elm's HTML engine conceptually the same as React+Redux and Om Now. It's just a big single atom app state with ways to describe how to update it. It has all the same problems as Om Now (maybe not quite as bad because it doesn't have cursors, but it doesn't solve the data-as-a-graph problem).

[masklinn]

> Elm's HTML engine conceptually the same as React+Redux and Om Now. It's just a big single atom app state with ways to describe how to update it. It has all the same problems as Om Now (maybe not quite as bad because it doesn't have cursors, but it doesn't solve the data-as-a-graph problem).

That's really not true. The nature of the Elm architecture means it already does this:

> Instead, Om Next asks you to define a set of mutation operations which can change your application’s state.

except it calls that "the `update` function".

The graph problem also seems slightly different, although it is way less convenient than Om Next as it is less declarative and must be bubbled through intermediate "components", Elm "render state" (and render hierarchy) doesn't have to match the application state, it's perfectly possible (and very useful) to duplicate, denormalise and process application state during rendering to match your rendering hierarchy (although it is a very bad idea to denormalise the application state itself).

Elm's trouble is mostly the "remote mismatch".

[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.

[fnordsensei]

Om Next has dropped the use of cursors.