I was looking back at our first "big" (as in not the tiniest of toys) Elm app and at its tendency to factor the model based on the view hierarchy. This had struck me as a dubious pattern at the time and there is a strong argument voiced by some that one should just stay flat as long as possible. But why had we done it this way? Some of it certainly stemmed from the emphasis in the TEA documentation at the time on how one can nest model-update-view-message quads. But another part stemmed from wanting to use Html.Lazy fairly aggressively. That desire also led to more logic that tried to avoid generating new values when existing values would do.
So, my question in retrospect is: How important is using Html.Lazy to performance? Is it something one should put in at obvious break points where there are expected to be large subtrees? Is it something that should be used close to the leaves with the internal tree largely left non-lazy? Is it something that you ignore until it seems like things aren't fast enough and then start trying to contort your model and view to make lazy work? My expectation from years of development is that on performance issues, one shouldn't go putting in more complicated code for problems that aren't yet known to exist — e.g., just sprinkling in laziness everywhere — but one should plan for what one would do if performance became a problem — e.g., if this were an issue, we could make it lazy right here. Lots of people adhere to the first principle citing concerns over "premature optimization" but the second principle tends to get less attention thereby leading to "sand in the gears" that can never be adequately addressed. So, how import is lazy HTML and how does one best plan for its introduction where it proves necessary? Mark -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
