Prior Art

Many readers may feel like Mobius is "just like X" - and they are correct. Here's a collection of related concepts, tools and frameworks that we're aware of and some of which we have used when coming up with Mobius. Being aware of our biases, we don't want to try to make comparisons, but in general, the main difference between Mobius and many of these alternatives is usually one of:

1. Mobius Update functions return Effects as immutable descriptions of things that should happen rather than doing them directly or returning something that knows how to execute them.
2. Mobius Update functions decide atomically which Effects and state changes should happen for a given Event. Contrasting this with the common approach in redux-like frameworks, there is no ordering between (in, say, RxRedux when a SideEffect processes an Action (potentially leading to new Actions) and when the Reducer will do it. The Mobius approach makes it easier to handle races.
3. Mobius targets development in JVM/Android.
4. Mobius is a framework that encodes its ideas in a way that is less subject to interpretation than a more loosely defined pattern is.

Here's an unordered and incomplete list of related technologies, documents, talks and ideas that we are aware of:

• The Elm Architecture
• Haskell's State Monad
• Andy Matuschak's state machines
• Rx Workflows and also open-sourced
• Unidirectional UI architectures
• Cycle.js
• Redux
• Managing State with RxJava
• MVI
• RxRedux
• Grox
• Presenter First - similar to the Mobius Workflow.