Summary of what ferp is, and why you would want to use it.
Every interaction outside of your application is a side effect
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.
Effects should be composable
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.
State has nothing to do with presentation
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.
Is Ferp Right for Your Project?
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.