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.
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.
> 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.
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?
/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.