How does htmx reapply event listeners to HTML coming from the server via AJAX requests?

[VinnyVicious]

For example: let's say that I make an AJAX request that replaces an entire

and that table itself has buttons that I have addEventListener on. How can I repply those after htmx has replaced the content, in an efficient way? I'm basically having to reapply manually on htmx:afterSwap.

[MILLERMARRU]

Ran into this exact question before, so I checked how htmx actually re-attaches things on swap. Short version: it doesn't reapply your addEventListener calls at all, and it can't — when the server-rendered HTML replaces the <table>, the old DOM nodes (and everything you attached to them with addEventListener) are gone. There's nothing for htmx to "reapply"; it's brand new elements from the response.

You're already doing the correct thing by hooking htmx:afterSwap and rebinding manually — that's a legitimate, documented pattern (htmx exposes htmx:afterSwap/htmx:load precisely so you can (re)initialize third-party widgets or manual JS on new content). But for plain click handlers on buttons inside swapped content specifically, there are two ways to avoid having to do that rebinding at all:

1. Event delegation — attach the listener once to a stable ancestor that never gets swapped (e.g. the page's root container or document.body) and check event.target.closest('button') inside it. Since the listener lives on a node that survives the swap, you never need to reattach anything, no matter how many times htmx replaces the table's contents.
2. hx-on:click — if the handler logic is simple, put it directly in the server-rendered HTML via hx-on:click="...", so the behavior travels with the markup itself and is "reapplied" for free every time htmx swaps in new content, since it's literally part of the new nodes.

Delegation is the one I'd reach for here since you said "efficient way" — one listener on the container instead of rebinding N buttons after every swap.