Conference Presentation, Keynote
Introduction to Incr_dom: Writing Dynamic Web Apps in OCaml
- The framework aims to reduce web development complexity to the level of standard OCaml applications, leveraging the Elm architecture for its predictable pattern and the ability to share significant code between back-end and client due to a shared language, though compiler errors may arise for unshared changes.
- Incremental computation and specific cutoffs are critical for performance optimization, ensuring that only affected parts of the view are recomputed when the model changes, while
InkerMaputilizes efficient diffing algorithms to minimize work proportional to the map's size change rather than the total size. - Performance strategies for large datasets involve transitioning from lists to maps to resolve lag during counter resets and scrolling, though initial rendering may remain slow; partial rendering, which displays only elements within the viewport and uses
updateVisibilityandonDisplayfunctions to manage scrolling focus, is recommended to mitigate initial load times and jumping. - Future development plans include the imminent addition of an explicit component system and improved tooling, while current limitations involve the lack of a direct equivalent to Elm's command/subscription patterns, the need to reconstruct VDOM trees from the top without an InkerMap analog, and insufficient specialized tooling for graph-based UIs.
- Developers are advised that adding incremental computations can introduce overhead that negatively impacts performance for small models, requiring experimentation to determine the point where optimization benefits outweigh the costs.
- Testing approaches currently rely on inspecting virtual DOM output as HTML or manual application execution, with plans to develop dedicated testing frameworks, while server communication is limited to RPCs over WebSockets, necessitating caution against unthrottled continuous updates that could crash the browser.
- Asynchronous action handling presents challenges where scheduled actions may no longer align with the current model state upon execution, requiring explicit model checks before application; this is managed via the
scheduleActionargument within theapplyActionfunction, though it does not prevent the page from blocking other actions during long-running processes. - The framework avoids BuckleScript in favor of maintaining closer synchronization with the latest OCaml versions and easier maintenance, accepting the trade-off of less readable JavaScript output, and offers high control over performance through fine-tuning capabilities despite the current absence of explicit component concepts.