[tel]

React always feels to me to big a huge compromise between a nice statefree dataflow solution for UIs and "getting Javascripters en masse to actually use the damn thing". The entire existence of the state API is a highly visible example of this.

It reminds me a lot of Gabriel's divide between the New Jersey approach versus the MIT approach---React is far more viral in its current form, but better technology certain lives further down the path.

I went to the Boston React meetup a few nights ago to hear Pete Hunt speak about React. He was a wonderful speaker and described nicely how React learned some of the same lessons that REST did making it superior to basic message passing and bloated/leaky distributed object mechanisms (blech). He also projected a very pragmatic POV from the React dev team---they want things to be right, but they also want things to be functional in the perspective of the way most applications are built today.

I was eager and jumped on some of the problems he suggested the React time was facing trying to integrate something like animation into React. At this point we jump from a sequence of instantaneous updates to a more game-like continuous redraw effort. Pete mentioned that the current effort here was to try to use technology like RxJS observers to get more reactivity and this seems aligned with the OP here.

Personally, I think animation lives most nicely in the domain of continuous time, "true" FRP which is mostly ignored by the current wave of Javascript FRP libraries. Perhaps for good reason since most modern implementations ideas of (again, "true") FRP are challenging to implement efficiently and the semantic model is probably far too large (Zeno processes, difficulty with infinitesimal delay).

But the advantage of FRP is that you can specify things like animation independently of the icky details like event passing and sampling rate and let those be determined at a later time when your FRP eDSL gets compiled into a more refined event-passing network. In other words, FRP languages hide a vast number of irrelevant and muddying details in a way that has a consistent denotation and can (perhaps!) be compiled efficiently into a push/pull message passing network.

[seanmcdirmid]

If you only care about animation, why not just use a constraint solver like a physics engine? Time step is set st run-time, constraints are quite natural (springs to pull something in). Constraint programming provides the declarative data binding feel of FRP behaviors (someone on my committee pointed that out). What you don't get with constraint systems are event streams, but that isn't so useful for UI programming anyways.

We had this discussion a while back:

http://lambda-the-ultimate.org/node/2913

[tel]

I think that's a really great idea, too. The worrisome bit around constraint solvers is that they're really easy to get into strange "spooky action at a distance" states of constraint interaction which are incredibly tough to escape from. Building good constraints thus feels like something of a black art.

[seanmcdirmid]

Sticking to Newtonian rather than using quantum physics can avoid the spooky action at a distance problem (I know this isn't what you meant, but I couldn't resist).

Actually, constraints are quite explicit compared to imperative assignments.

[tel]

Ha, and I had to speak of it that way for the same reason.

I believe that constraints are explicit, but their cumulative effect is difficult to predict. A constraint which wipes out some part of the feasible space with lots of vertices can have sudden and dramatic (non-local) impact on the solution. If your solver is approximate or your solution non-linear it might be incredibly difficult to figure out where the solver will ultimately land.

[seanmcdirmid]

I have found Verlet integration with an implicit velocity to be really good in this regard. It doesn't conserve energy very well, but it is very easy to work with (predictable) when doing animations since constraints are expressed by updating particle positions directly. I wrote a half baked paper on this once:

http://research.microsoft.com/pubs/191705/uiphysics09.pdf

[tel]

I'll take a look; thanks!

[kuni-toko-tachi]

Excellent and well said.