9 comments

[ 2.8 ms ] story [ 31.7 ms ] thread
I really like what this library does, but I'm troubled by the author's blatantly incorrect use of unsafePerformIO.

Correct functionality depends on specific use patterns, rather than allowing the type system to guarantee it. When the issues were reported, the author made several incorrect claims about the safety. When the claims were demonstrated to be incorrect, the author replied that you just shouldn't do the things that break it.

The whole thing left a pretty bitter taste in my mouth. The library can be used to do cool things, but it subverts the type system unnecessarily and blames the user when it goes wrong.

Is this the discussion you're referring to? https://github.com/reanimate/reanimate/discussions/210

It's actually pretty interesting to read. The author makes a not totally unreasonable argument as for why it uses unsafePerformIO.

Now what I'm really curious about is why the very first example on the site I clicked into the source code for, a simple 59-line example, is using unsafePerformIO. That actually worries me more because it suggests that as a user I might have to use unsafePerformIO. https://github.com/reanimate/reanimate/blob/d4d3898831edb4aa...

> Now what I'm really curious about is why [...] a simple 59-line example, is using unsafePerformIO

It seems to me that they are using the physics engine Chipmunk2D for that Animation which has bindings with IO in their signature.

The Reanimate site says that it ships with Chipmunk2D, and the example I linked shows both

  import Chiphunk.Low
  import Reanimate.Chiphunk
However I can't find any reference to Reanimate.Chiphunk anywhere, and if I search the repo for "chiphunk" I just see this example file, the readme, and a couple of YAML files. So I am very confused now.
Love the map projections animation inside of the examples!
But given that this needs to be displayed in a browser eventually, why not use libraries like the d3.js that are mentioned anyway? Seems a lot less complex?
Yeah, I wish this project had a React component backend.

D3.js and Observable Plot don't work that well with modern reactive frontend frameworks either though. They don't diff the SVG tree. The recommended way to react to some data change is to rebuild the whole SVG in a useEffect [1], when in fact you could just have a reactive SVG tree [2]. You just have to unpack and recode what would D3 do (see the case about Axis in the last link). Using enter(), update() and exit() seems to no longer be the way to do things. Also, React components offers great composability to the programmer.

I wish there was a maintained React version of Observable Plot; just like what React-Three-Fiber [3] does with Three.js. Or maybe a version of this Reanimate lib into a React component.

[1] https://github.com/observablehq/plot-create-react-app-exampl...

[2] https://wattenberger.com/blog/react-and-d3

[3] https://github.com/pmndrs/react-three-fiber

GHC now has official JavaScript and web assembly backends