State

There’s no intrinsic idea of state from this perspective. There’s just a change in an input resulting in a new output. State might be an implementation detail with how the app handles its inputs, but it’s not necessary. It’s not intrinsic to the idea.

Most problems worth solving have some intrinsic state. State can be essential. But that’s not how we treat it. We solve everything with state. Because we treat all the inputs to our app as different things—a touch event here, a web response there—we can’t combine them in any meaningful way. We can’t transform them uniformly. And so our only tool for dealing with all these different things is state. When our only tool is state, every problem looks like a stateful nail.

State is bad. State introduces complexity. And worse, it introduces complexity that grows more than linearly with the size of our app. We’re in the habit of constantly introducing more state into our app. New feature? New state. New complexity. New bugs.

But happily this perspective of our app’s output as a function of its inputs over time gives us a new tool: functional reactive programming. Functional reactive programming (FRP) is a paradigm built around the idea of time-varying values produced by time-varying functions.

Josh Abernathy, Input and Output