4 ms·

>htmx, for example, allows you to place many attributes on parent elements in a DOM and avoid repeating these attributes on children. This is a violation of LoB

>htmx, for example, allows you to place many attributes on parent elements in a DOM and avoid repeating these attributes on children. This is a violation of LoB, in favor of DRY, and such tradeoffs need to be made judiciously by developers. This is correct but this has little to do with DRY. This is more about making connections clear, which parents tinkering with children in non-explicit ways does not. >The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it. Richard's quote at the top of the article was not about deleting or inlining all abstractions so that the code is all in front of the programmers face, it was about making connections or dependencies clear. DRY flat out helps with "Locality of Behavior" by giving the programmer confidence that if they change so-and-so variable or function it will be updated properly throughout the code base. Non-DRY code would require a programmer to search the entire codebase to make sure their change is propagated properly. Not very "local". It also lets the maintainer focus on the LOCAL code instead of wadding through 60 lines of boilerplate such as "setup sql connection". Basically please avoid conflating DRY with syntactical duplication.

recursivedoubts 4y ago
i think this is a case where, if you aren't familiar with htmx, the given example isn't clear. I'll make it more concrete: <div> <button hx-target="#someDiv" ...> ... </button> <button hx-target="#someDiv" ...> ... </button> </div> Here we have two buttons that both target the div `someDiv`. We are repeating that information across both buttons. In an OO language we might be tempted to create a base class or dependency inject this behavior to avoid this repetition, ie to keep things DRY. In htmx, we would hoist this to the parent div: <div hx-target="#someDiv"> <button ...> ... </button> <button ...> ... </button> </div> This eliminates the code duplication on the two buttons, we are no longer repeating ourselves, but at the cost of sacrificing some locality of behavior. Here, the decrease in LoB is relatively minor, but the further you move from the buttons the more serious the violation is. I think the concepts hold up, when considered in this light.
- jackblemming 4y ago
  That would be called implicit structural coupling for the benefit of reducing syntactic boilerplate. And as you note, sometimes it can be a good trade. Much like functions that have to be called in a specific order are called "temporarily coupled"

recursivedoubts 4y ago

i think this is a case where, if you aren't familiar with htmx, the given example isn't clear. I'll make it more concrete: <div> <button hx-target="#someDiv" ...> ... </button> <button hx-target="#someDiv" ...> ... </button> </div> Here we have two buttons that both target the div `someDiv`. We are repeating that information across both buttons. In an OO language we might be tempted to create a base class or dependency inject this behavior to avoid this repetition, ie to keep things DRY. In htmx, we would hoist this to the parent div: <div hx-target="#someDiv"> <button ...> ... </button> <button ...> ... </button> </div> This eliminates the code duplication on the two buttons, we are no longer repeating ourselves, but at the cost of sacrificing some locality of behavior. Here, the decrease in LoB is relatively minor, but the further you move from the buttons the more serious the violation is. I think the concepts hold up, when considered in this light.

jackblemming 4y ago
That would be called implicit structural coupling for the benefit of reducing syntactic boilerplate. And as you note, sometimes it can be a good trade. Much like functions that have to be called in a specific order are called "temporarily coupled"