Html.fragment : List (Html msg) -> Html msg

Request Feedback
33

I recall looking into batch for both Html and Attribute when I was implementing elm/virtual-dom, and I recall a few considerations that led me to not add it at the time:

  1. It’s would be quite difficult to implement efficiently. I do not recall the exact specifics, but I think it clashed with certain data structures I was relying on to get the good performance numbers. E.g. how should diffing work when you cannot align nodes one-to-one between frames? Should a fragment be flattened? But wouldn’t that cause catastrophic diffs for all subsequent nodes in an unkeyed setting? Yes! Okay, but then what do data structures look like to protect against that? Very extreme care would need to be taken so that adding such a thing would not push Elm out of the top contenders on perf. (Special care is needed to make sure a JS VM can specialize code, like keeping object shapes perfectly uniform, and I recall thinking that was part of what made this idea difficult.)

  2. I did a decent amount of work to make elm/virtual-dom as small as possible while still having great performance, and I suspect that resolving the diffing question above would come at a notable size cost if perf was maintained overall.

  3. I had a weird feeling about it. Would it make code more confusing and unpredictable in certain ways? Maybe it is that func : Html msg -> Html msg seems to be declaring unambiguously that a single node will be passed in, and with this addition, it’s not saying that anymore. I could not tell if that was bad or neutral. I just had a weird feeling about it.

If you are into this idea, I would recommend working through (1) and (2) to prove that perf is not degraded by such an addition and see what the size change is for Hello World, TodoMVC, etc. If it is degraded, I’d consider that a major mark against the idea. From there, it’s more plausible to have a discussion about (3) whether the “surprise factor” of a Html msg actually being 100 nodes during a debug session is an okay price to pay. Seems like a high cost compared to using ++ where the structure of the DOM would be explicit in the code. But like I said, I don’t know really. I just felt weird about it. I personally dropped that line of thought as I came to understand the implementation challenges :sweat_smile:

Anyway, I hope these recollections are helpful.

11 Likes