[exiguus]

I think it depends on how seriously you take the frontend. Serious in the sense of design system, component library, reusability, accessibility and how well you want to test the frontend and its components in all variants independently. Then there is the independent work. Separation of concerns would be the keyword.

If I now look at how I use htmx in go, I need something like templ to develop reusable components that I can test independently. To be able to work independently, it would make sense to mock the properties of the components. So I could build a design system or component library with go and htmx that I can test before I use it in the "real" application. That's how I know it from the Ajax era, when SpringBoot was used, for example. You copied the html of the frontend component and "translate" it into Spring. When I remember that time, I praise today, when it is enough to have an openapi spec with which you can make agreements.

On the other hand, I clearly see the advantage of htmx if the project has one or two developers and you use an already finished design system or component library.