I am grug

HTMX doesn’t violate SoC, it’s that most people don’t fully understand what SoC MEANS. There’s no hard fast rule in what defines a concern. “This code converts text to uppercase” is a concern. “This code fetches HTML from a remote server then replaces the innerHTML with the result” is a concern. A concern is what you define it as in the scope of creating a feature or set of features. If it takes 20 sentences to describe the feature, and you can justify not moving some of the functionality out, it’s still a single concern. We don’t separate CSS, JS and HTML because of SoC, we do it because these are fundamentally different things that apply to the browser environment differently. Sure, most features that get added to a browser have a related JavaScript interface to manipulate it, but that isn’t because we are expected to use JavaScript for these features (there’s exceptions and those exceptions often suck, see web components*) SoC is about not having your blender also function as a toaster; it’s about not putting loosely coupled code where it doesn’t belong. HTMX by design actually enforces SoC, because it brings the relevant MEANING closer to the source. It doesn’t move the concern closer, it’s still a JS library living in the JS space, it’s separate. All this to say I disagree with his take on LoB vs SoC. These seem related, they seem linked - and you can easily make a case where certain code does favor one over the other but they are not mutually exclusive. HTMX handles LoB perfectly fine, but it’s a matter of breaking down what defines the behavior and what defines the concern. Sometimes these are the exact same thing, sometimes they’re completely unrelated. You can think of these like their own box placed around sections of code to create logical groupings. LoB is “where is the code that implements the behavior”, SoC is “where is the code that fulfills the concern.” And to that point, inlining isn’t bad, the act of doing so doesn’t inherently violate LoB or SoC. Neither does putting your CSS, JS and HTML in different files. In fact this is a very critical concept to understand semantic HTML: * HTML defines the shape of the document * CSS defines how the document will look * JavaScript defines the behavior of the document With HTMX you’re NOT putting a button handler inside the HTML. You’re putting a descriptor in HTML that - on the JS layer - is grabbing and acting upon it. They are still separate! The JQuery example is a bad one - not for the article, it’s great in that context - but selecting a specific element to add behavior is what violates SoC and LoB. For SoC, you don’t “grab this element and add behavior” - you abstract with “any element that matches this selector utilizes this behavior.” This also corrects LoB because now: * the HTML defines the shape * the JS defines the behavior So the key here is mirroring HTMX - put in place in the HTML what you want the JS to describe the behavior for. (Note on Web Components, I love them but acknowledge that the current pattern of not just describing the behavior but also the validity of and proper construction of in JS for what lives in HTML a major misstep, but one many are trying to come to a more solid consensus of before moving forward with proper changes)

good advice from grug

“Just copy and paste it” is not the advice you expect from a veteran engineer. But sometimes chasing DRY leads to more complexity, not less. @htmx_org breaks down why duplicating small bits of code might actually save your sanity in this week’s Dead Code.