Declarative UIs in a functional language
summary
An in-house functional language runtime evolves from a 2010 widget API to profunctor view nodes and custom handlers, cutting a text-change render from 6.0s to 0.5s and then to 0.02s while function calls fall to 146; the library uses a node-based view (not a virtual DOM hashing pass), per-node equality memoization, and monadic handlers that run IO and update model state without spamming messages. It ships in production across 100+ internal apps including a large intraday risk UI and meets the stated performance goals.
AI-written summary · about
chapters (11)
- 0:00Declarative UIs in functional languages
- 2:27UI libraries at Standard Chartered
- 3:33Widget library and limitations
- 8:30Declarative UIs and Elm architecture
- 12:44Performance issues with first approach
- 16:38Virtual Widget 2 for performance
- 22:58Node-based views: dynamic vs pure
- 26:12Testing Virtual Widget 2 performance
- 27:40Memoization for view rendering
- 28:46Improving ergonomics with handlers
- 33:44Virtual Widget 2 success today
related talks
43mEvolution of Functional UI Paradigms
40mFunctional Client-Side ClojureScript UI Programming with Webfui
34mFunctional UIs and Unidirectional Dataflow
43mFunctional UI, Functional Apps
38mThe challenges and benefits of a functional reactive frontend
45mJanus: Easy Complex UI with Declarative FRP
33mThe Functional Final Frontier
41mFunctional Programming for Pragmatists