ryantrinkle
commented
9 years ago Hi @GetContented,
- Reflex-DOM doesn't currently use requestAnimationFrame, but it is on the short list of features to add next.
- I have written large apps with reflex. The total number of components does not impact the performance of the FRP system - only the number of components actually changing in a given frame. If you have a specific component you're thinking of, I'll be happy to look into it in more depth.
- Debugging is much like debugging in Haskell in general. It's possible to run Reflex-DOM apps in ghci, so you can follow a pretty standard workflow. You can also use traceEvent/traceBehavior/traceDyn to show FRP signals as they are propagating, and you can use 'display', which is like 'print' except that it dumps a dynamic thing into the DOM. In my experience, not a lot of debugging has been required for Reflex apps. We don't have DOM-element-based exception handling; it's an interesting idea, but I haven't seen too many places where I needed it.
GetContented
In considering reflex DOM, I'd really like to know if you use requestAnimationFrame to batch your updates, or if you do them directly. I have an app which uses ClojureScript, Reagent and therefore ReactJS, and Reagent uses a requestAnimationFrame batching for efficiency reasons.
Have you done performance tests with thousands of components passing data on the same page? My app has this context.
It's my aim to migrate the app that runs our content management system to purely be written in Haskell, but I'd like to know whether it'll run performantly in Reflex-DOM before I consider it.
Also what's the debugging story like in Reflex-DOM? (Meaning, if something odd happens in the DOM, does it report error messages nicely so that one can track down which component has done something weird if that's the case? Or are these kinds of errors just not an issue?)