Explore performance implications of high frequency change over a large and deep tree

[lukebayes]

How would nomplate perform if we present a simple application shell (header/left nav, etc.) with an interior presentation of tabular data that has 10000 rows and 20 columns?

• Some UI components (or utilities) should exist that make windowing dead simple (so that only those data that are on screen or adjacent to the screen get rendered into UI components).

• The builder model makes it difficult to memoize component declarations. I looked into making components always accept data args and return the component tree, but this hurts readability and usability b/c each nested closure would need to have a return statement that returns a single node. I'm considering ideas here around component factory functions that might wrap a component definition, but this feels kind of complex. More exploration is needed.

• We can certainly deliver gains by switching to the DOM diff strategy before rendering if the tree exceeds some size or complexity score, but I'd like to do the same for the NOM tree as well. I suspect this could impact clients in that each one would need a unique instance of the builder in order to hide the cache. Perhaps something like:

const dom = require('nomplate').dom();

[lukebayes]

Speculative optimizations don't sound fun. Waiting for real world use cases to drive complexity.