If does work with nesting, it’s just less efficient. If the nesting happens in a big for loop, you simply send the result of the for loop as a dynamic substring. It’s not optimal, though… The user must write the template using as much concrete EEx syntax (no nested templates, no reusable widgets, etc.) as possible. Unless the widgets are macros, in which case we can expand them and isolate the dynamic parts (should be a fun exercise in static analysis). It’s still strictly better than sending the full webpage.
To do better than that one probably has to do some hardcore static analysis (which I believe Drab does).
Exactly! Besides saying that sending less data is always better, I don’t think there are many hard and fast rules here.
But if I had to bet, and without any hard data to look at, of course, I’d bet it will be hard to do better than our (yours and mine) naive approach of going only one level deep with no fancy caching of substrings besides what we get for free when using IOLists.
EDIT (further baseless speculation): going deeper than one level is tempting, of course, but then you need some sort of caching to compare the previous tree to the new one (and congratulations! you’ve just implemented your simplified VDOM on the server!). And caching consumes non-trivial amouns of memory. Maybe one could use checksums? If you checksum a string into a small int (< 32bits, for example) you get a negligible probability of collisions with a very low memory overhead. As long as the checksum function is fast, it could work. You could turn the (nested IOList) into a tree of checksums, which would be very easy to diff agains the old one (like a Merkle Tree with no cryptographic hashes) with a non-cryptoraphic hash. Diffing HTML on the blockchain, yeahhhh baby!!!. I should stop now. But baseless speculation about algorithms is fun!
