It's a bit pain to update nested types in elm, that's why I've often ended up having data that can change as flat as possible. But that also means that a too big a model is passed around between functions I guess, because it's annoying having to extract and pass the 3-4 values it needs.
What would happen if the view functions in elm by default were lazy? Since everything in elm is immutable, and the functions can't have side effects, it shouldn't be able to break anything. I guess the problem is that this kind of memoization can be memory heavy? But it doesn't really have to memorize everything. Just the last inputs, and then do nothing with the DOM if the inputs are the same. And the inputs are all derived from the main model, which is only ever updated one place in the runtime. So just keep track of changes when that happens, and what functions that affect, hmm.
`lazy` incurs a performance penalty not in memory but in execution steps, due to having to do a deep-equality comparison on the prev/next view inputs in the underlying JS. Enabling such a check globally would, on balance, slow everything down. Only if the work of running the view exceeds that small penalty, would you want to use it strategically here and there, hence the reason it's opt-in.
Even if the Records and Tuples proposal[1] lands and Elm gets refactored to use it internally, thus allowing `===` comparisons in the underlying JS instead of deep-equality, it's unclear whether enabling it globally would be good or bad, simply because the JS engine itself would presumably still be doing some kind of deep-equality check behind that innocuous-looking `===` operator. When the time comes I'll be curious to see if there's any progress on that front.