You could use a merkle hash tree where each Merkle node closes over the template inputs (eg comment.id, user.is_admin?) and optionally a hash of the template co

You could use a merkle hash tree where each Merkle node closes over the template inputs (eg comment.id, user.is_admin?) and optionally a hash of the template code (Unison language makes hashing code very easy since code in Unison is content-addressed https://www.unison-lang.org/docs/the-big-idea/ https://www.unison-lang.org/docs/the-big-idea/) The Merkle hierarchy is the same as the UI hierarchy, and by using a unified cache key system (just send the node id) you can optimize batch fetching of cached views anywhere in the hierarchy, even batching across requests if you have some QoS to prevent very deep trees in one request from stalling simple requests. Before adding caching to a UI rendering system, it's worth considering where the "slow" comes from. Is it data dependencies to feed the UI, or actually building the UI render result? It's possible caching at another layer might be more effective - if building the template inputs is uncached but takes 15ms, building the UI from scratch takes 5ms, and getting the UI from cache based on its inputs takes 3ms, the fancy UI cache system doesn't seem worth it - more effort needs to go to optimizing the data access layer. Using too fine-grained a cache for the UI layer can actively harm performance. At best UI building is a little bit of string math, and that can be much faster than a network call in most programming languages. In Javascript at least, rendering all of the example templates in the blog post would take microseconds.