For WebGL2 (no use of Virtual Dom), does Bonsai provide any benefit over Incremental?

Consider a typical WebGL2 app like, say, this demo: Planet

There is a big Canvas that WebGL2 draws to and there is a bunch of DOM elements for the GUI.

So now my question is: suppose we want to add functional-reactive-programming to the WebGL2 rendering part (no manipulation of DOM nodes, just calling the WebGL2 api). In this situation, does Bonsai offer anything over Incremental ?

main question: For WebGL2, does Bonsai offer anything over Incremental ?

argument for no

It is not obvious to me what advantage Bonsai provides in this case.

argument for yes

Incr_dom = Incremental + Virtual_Dom
Bonsai = Incr_dom + some other stuff, like Bonsai.Computation.t

So it seems that Bonsai is providing something useful to FRP that is in neither Incremental nor Virtual_Dom.

return to original question: What is this “something” and is it useful for WebGL2 apps ?

Incremental is a DSL / runtime for self adjusting computations. Bonsai is a library for building and running pure, incremental state machines. Unlike with Incr_dom, Bonsai isn’t actually restricted to producing DOM; for example, here’s a prototype of using Bonsai with Wall, a 2d graphics renderer.. As mentioned in the tweet thread, there are plans to eventually build a WebGL backend for Wall, so Bonsai would eventually have first class support for WebGL.

Anyways, back to your question. The biggest advantage of Bonsai is state management. If you want your web app to be interactive at all (some kind of config / state change, or RPC call in response to user interactions, or a timer, or component load, or anything else, Bonsai is all about storing and updating that state in response to “things that happen”.

Ok, let’s say you don’t want an interactive web app; you just have input data, and want to statically display all of said data. How is that data going to flow into your web app? Bonsai’s new Rpc_effect module allows you to poll RPCs, or send one-shot calls if needed.

And putting all that aside, let’s say you’ve built an incremental app that generates some representation of WebGL. You still want to run that in the browser. Bonsai makes that trivial.

By the way, SAC and FRP (aren’t quite the same): Jane Street Tech Blog - Self Adjusting DOM and Diffable Data.

  1. Thank you for the detailed explanation.

  2. Unrelated bonsai question: Is there a simple way to see the Incr_dom that all the %sub %arr compiles down to ? I have questions regarding “when” “what” happens that I think can be best answered by reading the “bonsai compiler output”.