Does your app generate a random number, get the current timestamp, or handle user input? If so, you are relying on side-effects. Side-effects, or simply effects, aren't bad at all, but they can make testing and logic hard. Ferp's update loop puts the power of controlled effects into the hands of every developer.
In most cases, effects cause other effects. For example, to add a notification in the browser, you must first ask permission. These are two separate side effects that should be able to be composed, something like
notifyPermit(notifySend('Holy notification, Batman!')). This pattern can prevent unnecessary update calls, and keeps side-effect producing code out of your state.
Much like many state management libraries that have come before, ferp has no preconceived notion of how you want to present your app. Use your favourite front-end or back-end library, or your custom one-of-a-kind solution. I would even argue that presentation is a form of a side-effect, since it often times modifies state outside of your applications control.
Ferp solves a certain combination of problems, but it does not claim to be the most correct way to solve these problems. The following table compares some of the key features of ferp to other popular libraries.
Number of stores
Consider the problems your application is going to face, and evaluate all your options. This includes considering the libraries you may import, the existing code you have, and of course, the features you need.