We can also have look at Masterminds/sprig to extend the default template functionality of Go.

After tinkering with htmx a bit, we decided to refactor the current quick-and-dirty UI solution with it to tackle the future challenges of the UI. Improvements done in this task will be:

• sub-templates / components for reusable UI parts - we'll stick to the builtin Go templates for now and maybe extend it with sprig when we need it
• avoid full-page reloads with htmx
• design more use-case specific endpoints instead of the one all-in-one endpoint we have right now - also in accordance with the hypermedia approach (see e.g. https://htmx.org/essays/10-tips-for-ssr-hda-apps/#tip-3-specialize-your-api-end-points)
• introduce websockets (using the htmx websockets extension) to push all kinds of serverside updates to the client (for now, needed for Refresh installation status on the UI automatically #164 - but also keeping in mind that future features might need such updates as well)

Right now we don't see a need for another JS-library, but if there should be cases in the future, where pure client-side interactivity is needed (i.e. a change on the UI that does not trigger anything on the backend), we could look into alpine.js