Hacker News new | past | comments | ask | show | jobs | submit login

Isn't Redux FRP? You can easily do the basics in React as well. I would say it's the dominant paradigm in UI development and most don't know they're using it.



Having worked with both Redux and a "real" FRP implementation (Haskell's Reflex library), I wouldn't call Redux FRP.

In Redux one explicitly, imperatively sends messages to a top-level message dispatcher, which then invokes more imperative code.

This feels /very/ different to Reflex's folding over events, and transforming dynamic values with pure functions.

The API you use is pretty different as well; consider:

* https://github.com/reflex-frp/reflex/blob/develop/Quickref.m...

* https://github.com/reflex-frp/reflex-dom/blob/develop/Quickr...


Completely agree Reflex is proper FRP. Redux does have some of the basics of FRP and you can stick to pure functions as well, which is limited by JS but not necessarily by the Redux pattern. I believe Redux is subset of FRP, that uses discrete commands instead of continuous function of time, and the time function can be made into descrete events for implementing commands. The rest builds on top of that.


To me, the core of FRP is hiding state. You couldn't look at a FRP program and say, "Yeah, here's where we define value X". Instead, you'd see various time-varying functions and the manner in which these functions are composed will implicitly define the state.

I think Redux isn't true FRP because it's very much about defining state. You plainly state every variable your program needs, while in FRP, variables just don't exist.


Hiding state is more the priority of declarative programming. FRP being declarative definitely does that, but I think the update loop is what's at the core of FRP, namely function changes over time and how they compose together to create chains of function changes over time, or something like that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: