To my younger me: Please use 2 different resource URI for #htmx and non-htmx requests. It makes development much easier later even tough you could destinquish by htmx headers, you definitely have more "control" and less surprises as things grow.

e.g. /todos/<id> and /hx/todos/<id>

@resmo Interesting advice. I went the exact opposite way because I found that there was a lot of duplication in my handlers.
But lately, as my project has grown I'm realising that my handlers contain too much business logic anyway and I should refactor them. Doing that would probably make your approach a much better choice.
@cuboci @resmo Let the handlers only render stuff, keep the logic separate. I am working with both header based routing and URL path based routing, both works fine as long as the handler only implements a "router backend interface".
@sontags @resmo I generally try to do that but it's difficult to judge where to draw the line.
I need a lot of different data for my templates (using #templ) and I try to avoid doing a lot of logic in those. But the backend data model doesn't trivially map to the view data model, so something has to do the conversion. It's not always clear where to push that logic.

@cuboci @sontags

regarding "business" or core logic, it comes usually natural if you also implement a rest or graphql api and share the same logic --> core logic. in my web controller I usually ask myself is this code only releasted to UI? so then it's okay here.

@resmo @cuboci yeah, that seems about right