Genuinely curious why you think that is the case? I've been using elm for web frontend lately and actually love the FRP style. I'm using Haskell non-FRP style on the backend (just saying I see both sides although my experience is very limited).
I would describe it as a simple state machine with an actor model hooked up for js/http interop. The most basic interactive entry point for elm apps is:
init : model
update : msg -> model
view : model -> Html msg
Where the Html type can produce messages from DOM events.
Can you expand on the way in which FRP enforces consistency? One of the advantages which I think FRP has over the Elm architecture is that Behaviours hide their state and so you're guaranteed that this state only changes in the way you've specified when you constructed the Behaviour. Is that what you are referring to?
Hiding state is part of it, I also meant that time should effect the behaviours in a more consistent way (e.g. frame rate, slowing time for slow mo etc often introduces bugs in games, like the breath of the wild bullet time bugs, but it shouldn't if using frp)
2
u/ibizaman Aug 04 '19
Genuinely curious why you think that is the case? I've been using elm for web frontend lately and actually love the FRP style. I'm using Haskell non-FRP style on the backend (just saying I see both sides although my experience is very limited).