incr_dom

Very interesting! This somehow seems convergent with the model-level incrementalization approach that incr_dom [1] and its successor bonsai [2] are using. Have you had a chance to compare these? [1]: https://github.com/janestreet/incr_dom | https://www.youtube.com/watch?v=R3xX37RGJKE [2]: https://github.com/janestreet/bonsai/blob/master/docs/blogs/...

Any discussion about incremental UI should include Yaron Minsky's talk about Jane Street's OCaml framework, incr_dom from 2016: https://www.youtube.com/watch?v=R3xX37RGJKE Incremental is essentially an implementation of Adapton from 2014: https://www.cs.umd.edu/~hammer/adapton/ There is a big upset coming in the UX world as we converge toward a generalized implementation of the "diff & patch" pattern which underlies Git, React, compiler optimization, scene rendering, and query optimization. Two sleeper startups in this space that are going to make a lot of money are Frank McSherry's Materialize Inc. and Nathan Marz's Red Planet Labs. incr_dom source: https://github.com/janestreet/incr_dom Differential Dataflow: https://github.com/TimelyDataflow/differential-dataflow Declarative Dataflow Client: https://github.com/sixthnormal/clj-3df Crux

Differential Dataflow solves the second hardest problem in computer science - caching - by calculating the optimal reactions to an event that will maintain the client's view. Of course, this requires tracking client queries and state cursors. For more background, look at Adapton and Jane Street's incremental DOM implementations: https://github.com/janestreet/incr_dom

Jane Street's minimal OCaml-based incr_dom https://github.com/janestreet/incr_dom https://www.janestreet.com/tech-talks/intro-to-incr-dom/

Kind of curious if anyone's played around with using incr_dom with Reason: - https://github.com/janestreet/incr_dom/ - https://www.youtube.com/watch?v=h_e5pPKI0K4 Seems like it might be tied to js_of_ocaml though...

Qt, as long as you back the view with a model with O(1) lookup, can handle up to INT_MAX rows perfectly fast. I expect other cross-platform GUI toolkits work similarly. Most native table/list views work on an assumption of uniform row height and thus handle huge lists with no trouble. The problem browser based apps run into is rendering the entire list into the DOM and thus the browser has to lay out the whole thing in order to compute scroll bars and scroll positions. You can work around this using requestAnimationFrame, large empty padding divs, and inspecting the scroll position to create DOM elements for only things that you compute are visible. At my last job I implemented a web based table that could do 60fps scrolling on 100,000 items that were all dynamically updating using js_of_ocaml and https://github.com/janestreet/incr_dom.

Indeed, js_of_ocaml is kind of shocking in its fidelity. It can compile even highly complex libraries that do lots of runtime tricks. Async_kernel and Incremental_kernel both compiled and worked without any issues whatsoever. We've even built some support for making incrementally rendered web-apps in OCaml, using Async and Incremental. Here's a link: https://github.com/janestreet/incr_dom It sounds like Bucklescript is doing something quite different, which is to aim for pretty JavaScript output, while compromising and maintaining semantic consistency with OCaml. I don't fully understand the use-case, but for us, js-of-ocaml is clearly the thing we want.