I know the HTMX guy has opinions on this, but I also like how React (and similar frameworks) give you locality of behavior.
<button onClick={() => fetch(‘/clicked’)}>
To me that feels like less magic to remember than
<button hx-get=“/clicked”>
But ultimately let’s be honest: Experienced engineers can write good code in anything and inexperienced engineers can write bad code in anything. Simplicity takes time.
yawaramin · 12h ago
But...your code examples are not doing the same thing though. The React example just does a `GET /clicked` request and discards the response. The htmx example does a GET request and swaps the response into place, replacing the button. This is analogous to an `<a>` or `<form>` tag that makes a request, gets the response, and then replaces (ie swaps) the page.
Try making your React example do what the htmx one does. That's when you'll see the complexity start to creep in.
lblume · 11h ago
But how often do you actually need that when writing a reactive app? In most cases I have worked with you want the button to persist and load some external data that updates a reactive state.
yawaramin · 11h ago
Sure, try doing whatever equivalent makes sense in React. Then try comparing the complexity of the two approaches. The point is to compare apples to apples as much as possible.
tshaddox · 11h ago
> Experienced engineers can write good code in anything and inexperienced engineers can write bad code in anything.
I don't have strong opinions about this particular React/HTMX example, but I don't love this statement because it seems to be dismissing the possibility that some tools are better than other tools for a particular job.
marcosdumay · 9h ago
It is exactly dismissing the possibilities some tools are better than others for particular jobs, and it has been a popular phrase for people advocating for bad tools for decades.
The previous favorite one used to be "a bad craftsman blames his tools", that people that liked to impose bad tools on others repeated all the time. But that phrase got old.
Swizec · 9h ago
> it seems to be dismissing the possibility that some tools are better than other tools for a particular job
I think these are 2 dimensions. Great engineer + right tool is obviously the best combination. Great engineer + wrong tool can work surprisingly well. I have never seen the other 2 combinations produce elegant results.
But really what I was trying to say is this: We're just smearing complexity around. UI is hard. The component model won for a reason. Use whatever syntax you prefer, they're all fine, but please use composable components of some sort to build your UI.
yawaramin · 8h ago
Htmx doesn't preclude a component model for the UI. See:
That is the point I was making: HTMX is just a flavor of the component model.
yawaramin · 8h ago
Eh, not really. Htmx is a tool that you can plug in to your system. It doesn't dictate what system or architecture you use. You can have a component model, or you can have old-fashioned string-based HTML templates. Htmx is agnostic to that.
PaulHoule · 12h ago
I see it as mattering at a higher level.
I worked on a system (Themis) for creating ML training sets for big corporations which would basically show a screen that has the user make a judgement and then show them another screen and so forth.
We had to develop this thing at a breakneck pace and if it was successful, I'd have the expectation that we (or the customer) would always be developing new models and new tasks.
As it was this system had a React front end and a "microservice" back end in Scala. Everything was packed up and deployed with Docker. The engineering manager didn't believe me when I said that it took 20 minutes to turn around the smallest change in this system so we timed with it with a stopwatch and we measured 18 minutes. Notably if you want to add a new task you have to change more than one back end process and update the SPA. You had to be a skilled front end and Scala developer to change things yourself and if you're working on a team you are going to have a lot of back and forth which slows things down.
I had a counterproposal (Nemesis) that I've been using for Centaur processes [1] that I develop on my own account which is an old-school site enhanced with HTMX.
A task is implemented in a Python file using the flask API with a class that has a few flask methods for HTTP endpoints and a small number of Jinja2 templates which draw the HTML. [2] Adding a new task is a matter of adding a new class and a new template and deploying it is super-easy, turnaround on a flask server is instantaneous, it's just a few seconds with a production gunicorn server. It takes less programming skill than Themis, a new task can be created by cut-and-paste-and-modify or be vibe coded without risk of breaking other tasks.
Since it doesn't have lots of images, chrome, Javascript, metadata in the <head>, ads, trackers and crap it is crazy fast. On my tablet, going the wrong way on an ADSL connection, over wireless and my phone's hotspot, it feels like using a desktop application. The app has plenty of screens that do visualization with d3.js and other things with Javascript where necessary. If I had a task that required a very complex interaction then I could write an tiny SPA just for that task with React, Svelte or whatever I wanted.
[1] Human processes some tasks, AI processes some tasks, AI gets trained based on human performance
[2] The exact same architecture would work in Java with JAXB
perching_aix · 10h ago
> let’s be honest: Experienced engineers can write good code in anything and inexperienced engineers can write bad code in anything
Does this not scream "just the distribution of outcomes can drastically differ" at you?
Swizec · 9h ago
> Does this not scream "just the distribution of outcomes can drastically differ" at you?
Yes. My argument is that outcomes depend more on the people than tools.
perching_aix · 8h ago
How does that follow? Or are we talking past each other?
I tried to model this formally (well, to the extent I can model anything formally), cause this is a fun little exercise in a way, and got that at least as far as my toy model goes, it's a wash, both matter equally (since at the extremes, they will approach each other's distributions, i.e. the distribution of expertise or the distribution of tool choice).
Or to be more specific, what matters more is what you can change more, something I only accounted for in the very end. And I don't think significantly pushing the needle in expertise, especially in a way that persists over time, is realistic. People need time to gain expertise, so those with majority expertise will always be a minority. But improving tooling and doing so with long lasting effects is much more realistic. Hence, good tooling that leads your hand matters more. It raises the bar, and automatically ensures past mistakes aren't repeated without a need for costly rediscovery or specific training.
Swizec · 7h ago
I think we are violently agreeing.
Think of frameworks as "distilled experience". They help the next "generation" go faster because they don't need to make all the same mistakes. This is awesome.
But it is not magic. People will make a mess. Often because they hold the framework wrong and/or miss what it's trying to do for them. Or just don't grok the author's beautiful vision.
However, an experienced practician groks the fundamentals and can quickly adapt to any framework. Because all the frameworks are built on similar fundamentals so it's easy to hold them correctly. You go "Ah, the author believes X, so if we just assume X, it all falls into place and the code looks great".
That said, you might be working in a domain where X is fundamentally untrue. Then this is the wrong framework and an experienced practician will go "This is the wrong tool and choose a tool that fits better". The thing that doesn't fit may be the current team/experience moreso than the business domain.
At the end of the day more experienced engineers will produce a better solution than less experienced engineers. For a variety of reasons. Good tools can make less experienced engineers ramp up faster.
perching_aix · 6h ago
Oh okay, we are indeed in agreement then.
> That said, you might be working in a domain where X is fundamentally untrue. Then this is the wrong framework and an experienced practician will go "This is the wrong tool and choose a tool that fits better".
Agreed, this is always the money shot. I further think that the holy grail for advancements is for them to lead people's hands in a way that is self-justifying. It's a very tall and cruel order, but I think it's absolutely essential. If a solution fails to do this, people eventually turn on it, and adoption reverts or otherwise falls apart. I'm particularly worried about this happening to e.g. Rust, but this can be applied to basically anything.
joshmanders · 12h ago
> To me that feels like less magic to remember than
Ehhh, only seems that way because you're so entrenched in React with minimal htmx experience.
I've used both pretty extensively and they both feel similar in the magic aspect, except htmx is cleaner.
pier25 · 11h ago
> except htmx is cleaner
I've had the opposite experience.
Htmx does work for simpler use cases like submitting a login form. Beyond that it gets messy very quickly as you start introducing more backend endpoints for every little interaction. In some stacks you have template fragments[1] which alleviate this problem somewhat but still, htmx doesn't scale for more sophisticated interactivity.
And most projects will still need client-side interactivity. So now your features are a mix of htmx stuff, something client-side (Alpine, Vue, whatever), and probably some HTTP endpoints to interact with the client-side stuff.
You also still need to take care of CSS which htmx completely ignores because it's really just a low level HTML exchange protocol if you will. With Vue, Astro, or Svelte you can encapsulate markup, behavior, and styles in a single file.
And on top of all that, the DX is quite frankly terrible compared to doing frontend with something like Vite with hot module reloading. Most backend servers need to restart and maybe even recompile the whole thing. PHP is the only exception I know of since every request "runs the whole application".
The react snippet is one uppercase letter away from being vanilla js, it's definitely less magic.
yawaramin · 11h ago
I feel that as software engineers, instead of talking about things like 'feels like magic', we are capable of reading the docs and understanding what something actually does, especially when it's pretty simple: https://htmx.org/attributes/hx-get/
recursive · 11h ago
And if you made that change, despite being vanilla js, it still wouldn't work.
mock-possum · 12h ago
Or lit -
<button @click=${fetch(‘/clicked’)}>
qn9n · 12h ago
This is way too much magic, starting to look like Vue or Svelte
zdragnar · 11h ago
That's because lit templates are in template strings, so passing through a function requires the dollar sign and curly braces (that's just vanilla js). Everything else about it in the example, aside from using @click instead of onclick, is identical to react.
qoez · 12h ago
I remember learning separation of concerns and then react popped in and just threw that out the window and yet everyone adopted it. I still haven't recovered from the idea that these guidelines are very bendable etc.
dsego · 12h ago
There is separations of concerns and separation of technologies.
A component with its styling, markup structure, and behavior, is one concern. These components can than be combined and nested in every which way you need, they are very modular.
If you separate concerns into markup, styling, behavior, than this form of component-based reuse is difficult. But it could conceivably be easier to reuse an html template or css class for different features.
Hooks are also a way to separate concerns in a different way than lifecycle methods. Lifecycle methods group code by specific points in a component's life, but then the logic can't be extracted and reused. Hooks on the other hand encapsulate reusable logic that can then be used in different components.
kqr · 10h ago
Thank you for saying this so clearly. I find React to be one of the few systems that actually allow separation of concerns when used idiomatically, rather than drawing boundaries based on technologies. (And I dislike frontend programming, to be clear!)
Was it CSS Zen Garden that convinced a generation of web developers that HTML and CSS are in fact different concerns?
gf000 · 10h ago
So where is the booming community of CSS styles for popular websites, so that I can just change the way they look how I wish? Surely making one for Facebook would be no issue, right?
blturner · 10h ago
CSS was brand new. It was a showcase to show a generation of web developers who used HTML tables for layout (probably using Dreamweaver) how CSS and semantic HTML could be used to achieve the same result, but with readable code. In some ways, component-based architectures are just a re-hashing of the old paradigms we worked out of.
mystifyingpoi · 11h ago
> and just threw that out the window
Did it though? I've worked with React for some time, and we simply put all the non-view things into separate modules, or at least separate functions. React is (still) a library, it doesn't prevent anyone from mixing the layers and making spaghetti.
panphora · 12h ago
It's all bendable, always has been.
jonathan-adly · 11h ago
One of the most pleasant experiences I had writing code, is early AI days when we did hyperscript SSE. Super locality of behavior, super interesting way of writing Server Sent Events code.
on message as string
put it into #div
end
on open
log "connection opened."
end
on close
log "connection closed."
end
on error
log "handle error here..."
end
What if I want two kinds of buttons on the navigation bar?
Then you have two options:
- Abandon the idea. Do something simpler.
- Come up with a generic CSS rule for it.
For this idea to work, _you have to accept limitations_, which means you cannot design whatever looks you want, or make pixel-perfect layouts, etc. You have to work within some constraints.
recursivedoubts · 12h ago
yeah, this is a tricky area for us LoB enthusiasts: tailwinds is an example of LoB, but also I think sometimes it devolves into inlining implementation[1]. My gut reaction is to want a well named CSS class on the element instead, which feels like the equivalend of defining a function elswhere, but calling it on the element in question, thereby preserving LoB (to an extent)
On the other hand, I know a lot of very smart folks who like the tailwinds approach, and I do acknowledge the difficultly of naming CSS classes, that the function metaphor breaks down due to the fact that CSS classes have non-encapsulated effects on child elements, etc.
There's a middle ground which is having an optional <style> block in the page template, this allows you to express local style differences without going crazy with style attributes. And they are easy to refactor into a global style sheet if needed.
alganet · 11h ago
I think the web platform is really simple, easy to understand and great.
A. Your content is a document. A semantic HTML document, boring, mostly made of text.
B. You can make the document alter parts of itself with JS. You don't mess with appearance here, just change the boring document content.
C. You can make the document look good by applying some styles to semantic HTML tags.
If you respect them, you get both LoB and SoC neatly arranged into meaningful layers.
--
Tailwind-like stuff breaks semantic HTML. Classes like ".flex-7" are about style, not the text. CSS classes should be stuff like ".introduction" or ".cooking-ingredients".
It makes documents otherwise simple to read into a mess. Now there's appearance concerns hidden in between the content. It's bad.
--
All good rules come with great exceptions. In this case, stuff like Google Maps. You can't really represent it as a document. But that's rare on the web.
Somehow, people were convinced to use those "frameworks for rare use cases" to make simple documents, forms, etc.
--
Local <style> tags fall into this category of exceptions. Sometimes you need some extra style for a content that is unusual, but that's the exception. Most websites want to look consistent across all their published content.
incorrecthorse · 12h ago
The bad ID naming `d1` is convenient for the argument...
mock-possum · 12h ago
So is the assumption that the jquery is in a different file than the html tag - if you wanted to get real crazy about it you could have the script tag immediately after the button tag - you could even inline the onclick behavior with no jquery or htmx required. How’s that for locality?
I guess the point is not so much that you could do those things, but that it was fairly common during ‘the jQuery days’ to do as the author describes.
shelajev · 12h ago
"spooky action at a distance" sounds bad, but this is how most frameworks that embrace convention over configuration work. You add a dependency to your SpringBoot application and suddenly your app actually has new endpoints and config for them and so on.
Pannoniae · 12h ago
Yes, but that doesn't necessarily mean it's the right thing to do, it's a tradeoff. Convention over configuration is good in large teams for fast onboarding sure (just copy the previous pattern!) but it makes the last 20% of stuff harder and it especially makes debugging harder because all your IDE tools like "find usages" become useless.
xg15 · 4h ago
Still have bad memories of SpringBoot's arbitrary redefining of the semantics of dependencies.
Suddenly some accidental transitive dependency that you didn't even know existed and that is not even used by anything can completely change the behavior of your app...
hobozilla · 12h ago
Sorry in advance for bringing AI into this but... this is context engineering in a nutshell. DRY and SoC really mess with an agent's ability to efficiently gather context. If you limit all layers of a feature into a small area (e.g. folder) it's much easier to work with. Vertical Slice Architecture is a good example of this too.
ryeats · 10h ago
It's a good point though this is also what makes it easier for humans. I think most good abstractions hide unimportant details in order to make it easier to reason about and reduce the context but both the appropriate amount of context and what is an unimportant detail are not consistent between individual devs and don't have good metrics to measure their qualities.
khy · 12h ago
It's kind of an expression of the success of an abstraction. If an abstraction is good (hx-get="/clicked"), it feels local. If an abstraction is bad (id="d1"), it's spooky action at a distance.
dalmo3 · 12h ago
I've never used htmx, can you ctrl+click "/clicked" and go to definition? If not, it's just as spooky.
yawaramin · 8h ago
> can you ctrl+click "/clicked" and go to definition?
Actually, you can and you should–this is a best practice for building maintainable apps. You shouldn't be hard-coding 'magic string' API paths throughout your views. You should factor them out into variables and then use those same variables for both routes and views.
Many good routing systems have this functionality.
recursivedoubts · 11h ago
Have you ever used HTML?
Can you ctrl-click on an href attribute and go to the definition?
fkyoureadthedoc · 12h ago
can you do that on any button that makes a fetch/ajax call? if the target for /clicked is a full standalone page, why even have a button and not a link?
pphysch · 12h ago
HTMX can easily get spooky. One pattern to avoid that is to not use separate routes for HTMX endpoints. Instead, use a special GET param or header to tell the server that this request is for a specific HTML fragment.
/page1, /page1/click1 (bad)
/page1, /page1?htmx=click1 (good)
Then have a common server pattern for how you inspect the request to determine which fragment (or whole page) to respond with.
With this, navigating HTMX code is much nicer because you only have to identify one entry point instead of hopping through the codebase to identify the N different URLs and view functions that support the page.
recursivedoubts · 11h ago
For sure, for example, htmx has attribute inheritance, which moves behavior away from where it has effects, and allows you to listen for events on other elements, same problem.
The development principle still stands, however, and, like all dev principals, has trade offs associated with it.
pier25 · 11h ago
Styles are also part of the behavior of a piece of markup. Not the interactivity behavior but certainly the rendering behavior.
ribs · 12h ago
One would like to see the word “modularity” somewhere here.
Try making your React example do what the htmx one does. That's when you'll see the complexity start to creep in.
I don't have strong opinions about this particular React/HTMX example, but I don't love this statement because it seems to be dismissing the possibility that some tools are better than other tools for a particular job.
The previous favorite one used to be "a bad craftsman blames his tools", that people that liked to impose bad tools on others repeated all the time. But that phrase got old.
I think these are 2 dimensions. Great engineer + right tool is obviously the best combination. Great engineer + wrong tool can work surprisingly well. I have never seen the other 2 combinations produce elegant results.
But really what I was trying to say is this: We're just smearing complexity around. UI is hard. The component model won for a reason. Use whatever syntax you prefer, they're all fine, but please use composable components of some sort to build your UI.
- https://www.fastht.ml/
- https://github.com/yawaramin/dream-html/tree/todoapp/app
In fact if you look at how htmx is recommended to be used, you realize they specifically are recommending a component-based architecture: https://htmx.org/essays/when-to-use-hypermedia/#if-your-ui-i...
I worked on a system (Themis) for creating ML training sets for big corporations which would basically show a screen that has the user make a judgement and then show them another screen and so forth.
We had to develop this thing at a breakneck pace and if it was successful, I'd have the expectation that we (or the customer) would always be developing new models and new tasks.
As it was this system had a React front end and a "microservice" back end in Scala. Everything was packed up and deployed with Docker. The engineering manager didn't believe me when I said that it took 20 minutes to turn around the smallest change in this system so we timed with it with a stopwatch and we measured 18 minutes. Notably if you want to add a new task you have to change more than one back end process and update the SPA. You had to be a skilled front end and Scala developer to change things yourself and if you're working on a team you are going to have a lot of back and forth which slows things down.
I had a counterproposal (Nemesis) that I've been using for Centaur processes [1] that I develop on my own account which is an old-school site enhanced with HTMX.
A task is implemented in a Python file using the flask API with a class that has a few flask methods for HTTP endpoints and a small number of Jinja2 templates which draw the HTML. [2] Adding a new task is a matter of adding a new class and a new template and deploying it is super-easy, turnaround on a flask server is instantaneous, it's just a few seconds with a production gunicorn server. It takes less programming skill than Themis, a new task can be created by cut-and-paste-and-modify or be vibe coded without risk of breaking other tasks.
Since it doesn't have lots of images, chrome, Javascript, metadata in the <head>, ads, trackers and crap it is crazy fast. On my tablet, going the wrong way on an ADSL connection, over wireless and my phone's hotspot, it feels like using a desktop application. The app has plenty of screens that do visualization with d3.js and other things with Javascript where necessary. If I had a task that required a very complex interaction then I could write an tiny SPA just for that task with React, Svelte or whatever I wanted.
[1] Human processes some tasks, AI processes some tasks, AI gets trained based on human performance
[2] The exact same architecture would work in Java with JAXB
Does this not scream "just the distribution of outcomes can drastically differ" at you?
Yes. My argument is that outcomes depend more on the people than tools.
I tried to model this formally (well, to the extent I can model anything formally), cause this is a fun little exercise in a way, and got that at least as far as my toy model goes, it's a wash, both matter equally (since at the extremes, they will approach each other's distributions, i.e. the distribution of expertise or the distribution of tool choice).
Or to be more specific, what matters more is what you can change more, something I only accounted for in the very end. And I don't think significantly pushing the needle in expertise, especially in a way that persists over time, is realistic. People need time to gain expertise, so those with majority expertise will always be a minority. But improving tooling and doing so with long lasting effects is much more realistic. Hence, good tooling that leads your hand matters more. It raises the bar, and automatically ensures past mistakes aren't repeated without a need for costly rediscovery or specific training.
Think of frameworks as "distilled experience". They help the next "generation" go faster because they don't need to make all the same mistakes. This is awesome.
But it is not magic. People will make a mess. Often because they hold the framework wrong and/or miss what it's trying to do for them. Or just don't grok the author's beautiful vision.
However, an experienced practician groks the fundamentals and can quickly adapt to any framework. Because all the frameworks are built on similar fundamentals so it's easy to hold them correctly. You go "Ah, the author believes X, so if we just assume X, it all falls into place and the code looks great".
That said, you might be working in a domain where X is fundamentally untrue. Then this is the wrong framework and an experienced practician will go "This is the wrong tool and choose a tool that fits better". The thing that doesn't fit may be the current team/experience moreso than the business domain.
At the end of the day more experienced engineers will produce a better solution than less experienced engineers. For a variety of reasons. Good tools can make less experienced engineers ramp up faster.
> That said, you might be working in a domain where X is fundamentally untrue. Then this is the wrong framework and an experienced practician will go "This is the wrong tool and choose a tool that fits better".
Agreed, this is always the money shot. I further think that the holy grail for advancements is for them to lead people's hands in a way that is self-justifying. It's a very tall and cruel order, but I think it's absolutely essential. If a solution fails to do this, people eventually turn on it, and adoption reverts or otherwise falls apart. I'm particularly worried about this happening to e.g. Rust, but this can be applied to basically anything.
Ehhh, only seems that way because you're so entrenched in React with minimal htmx experience.
I've used both pretty extensively and they both feel similar in the magic aspect, except htmx is cleaner.
I've had the opposite experience.
Htmx does work for simpler use cases like submitting a login form. Beyond that it gets messy very quickly as you start introducing more backend endpoints for every little interaction. In some stacks you have template fragments[1] which alleviate this problem somewhat but still, htmx doesn't scale for more sophisticated interactivity.
And most projects will still need client-side interactivity. So now your features are a mix of htmx stuff, something client-side (Alpine, Vue, whatever), and probably some HTTP endpoints to interact with the client-side stuff.
You also still need to take care of CSS which htmx completely ignores because it's really just a low level HTML exchange protocol if you will. With Vue, Astro, or Svelte you can encapsulate markup, behavior, and styles in a single file.
And on top of all that, the DX is quite frankly terrible compared to doing frontend with something like Vite with hot module reloading. Most backend servers need to restart and maybe even recompile the whole thing. PHP is the only exception I know of since every request "runs the whole application".
[1] https://htmx.org/essays/template-fragments/
<button @click=${fetch(‘/clicked’)}>
A component with its styling, markup structure, and behavior, is one concern. These components can than be combined and nested in every which way you need, they are very modular.
If you separate concerns into markup, styling, behavior, than this form of component-based reuse is difficult. But it could conceivably be easier to reuse an html template or css class for different features.
Hooks are also a way to separate concerns in a different way than lifecycle methods. Lifecycle methods group code by specific points in a component's life, but then the logic can't be extracted and reused. Hooks on the other hand encapsulate reusable logic that can then be used in different components.
https://entropicthoughts.com/mvc-mistake
Did it though? I've worked with React for some time, and we simply put all the non-view things into separate modules, or at least separate functions. React is (still) a library, it doesn't prevent anyone from mixing the layers and making spaghetti.
eventsource demo from http://server/demo
end https://hyperscript.org/features/event-source/You just need to come up with CSS and JS that are not _specific_, but _layered_ instead, which is hard.
Bad:
Good (only this button): Better (all buttons on nav are the same): What if I want two kinds of buttons on the navigation bar?Then you have two options:
- Abandon the idea. Do something simpler.
- Come up with a generic CSS rule for it.
For this idea to work, _you have to accept limitations_, which means you cannot design whatever looks you want, or make pixel-perfect layouts, etc. You have to work within some constraints.
On the other hand, I know a lot of very smart folks who like the tailwinds approach, and I do acknowledge the difficultly of naming CSS classes, that the function metaphor breaks down due to the fact that CSS classes have non-encapsulated effects on child elements, etc.
Interesting case to think about.
[1] - https://htmx.org/essays/locality-of-behaviour/#surfacing-beh...
A. Your content is a document. A semantic HTML document, boring, mostly made of text.
B. You can make the document alter parts of itself with JS. You don't mess with appearance here, just change the boring document content.
C. You can make the document look good by applying some styles to semantic HTML tags.
If you respect them, you get both LoB and SoC neatly arranged into meaningful layers.
--
Tailwind-like stuff breaks semantic HTML. Classes like ".flex-7" are about style, not the text. CSS classes should be stuff like ".introduction" or ".cooking-ingredients".
It makes documents otherwise simple to read into a mess. Now there's appearance concerns hidden in between the content. It's bad.
--
All good rules come with great exceptions. In this case, stuff like Google Maps. You can't really represent it as a document. But that's rare on the web.
Somehow, people were convinced to use those "frameworks for rare use cases" to make simple documents, forms, etc.
--
Local <style> tags fall into this category of exceptions. Sometimes you need some extra style for a content that is unusual, but that's the exception. Most websites want to look consistent across all their published content.
I guess the point is not so much that you could do those things, but that it was fairly common during ‘the jQuery days’ to do as the author describes.
Suddenly some accidental transitive dependency that you didn't even know existed and that is not even used by anything can completely change the behavior of your app...
Actually, you can and you should–this is a best practice for building maintainable apps. You shouldn't be hard-coding 'magic string' API paths throughout your views. You should factor them out into variables and then use those same variables for both routes and views.
Many good routing systems have this functionality.
Can you ctrl-click on an href attribute and go to the definition?
/page1, /page1/click1 (bad)
/page1, /page1?htmx=click1 (good)
Then have a common server pattern for how you inspect the request to determine which fragment (or whole page) to respond with.
With this, navigating HTMX code is much nicer because you only have to identify one entry point instead of hopping through the codebase to identify the N different URLs and view functions that support the page.
The development principle still stands, however, and, like all dev principals, has trade offs associated with it.
(DRY was never about code repetition).