Entitas vs. FRP

Kind of close, but still so different.

In previous post I compared Entitas with MVC & MVVM. I feel chatty today so why not add another buzz wordy abbreviation into the mix.

As a representative for FRP I would like to chose ReactiveX because it is best documented, language agnostic and very trendy.

ReactiveX is a combination of the best ideas from
the Observer pattern, the Iterator pattern, and functional programming (http://reactivex.io)

In my previous article I mentioned that having a direct observer on entity or on a group is less code, but becomes much harder to reason about when your game / application grows. It is simpler to reason about a chain of reactive systems which have deterministic order of execution and aggregate changes over tick.

I believe it is due to the following fact:

Every application which involves human interaction has a run loop. This is a time based stream. Through introduction of Observers we create a bunch of independent secondary streams. They interrupt the time stream and they are executed in an non deterministic order. They know nothing about each other and there is no coordinator involved. Systems in Entitas are about coordinated state mutation. Now you might say FRP is stateless! Sorry to break it for you, but this is an “understatement”. ReactiveX implementations are as stateless as a View implementations in any MVC library. They are state-full and they hide state form the user. In order to make you operate in this wall garden ReactiveX provides over 70 Operators. Those operators let you create, access and transform state inside library classes.

This is why when using entity / group observing and bypassing the systems, we might end up in situation where we need operators like in ReactiveX.

As a matter of fact, last year I implemented a small conference App with Entitas-Swift, where I had no systems, just entity / group observing. And I end up implementing my own debounce function, because it was the simplest way to aggregate multiple changes.

To sum up. Every user UI based application has a run loop which is basically a time triggered stream. Turning user interactions into state and working with this state in deterministic chain of systems executed due to this stream, is the simplest way to implement reactive applications. IMHO

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.