htmx Browser-Server Swaps: Prioritizing Concurrent In-Flight Requests

Answer to the Core Question

By default, htmx does not queue overlapping requests. Each trigger fires an independent Ajax request that is processed as soon as the network response arrives. The DOM is updated immediately according to the hx-swap mode of that particular request. Consequently, the last response that arrives wins, regardless of the order the requests were triggered.

Swap modes such as innerHTML, outerHTML, delete, or none only define how the returned markup is inserted or removed; they do not enforce any ordering or cancellation behaviour between concurrent requests.

Confirmed Facts

• htmx allows multiple concurrent in‑flight requests; the browser’s HTTP/1.1 or HTTP/2 limits apply, but htmx itself does not impose a queue.
• Responses are applied in the order they arrive from the server, not the order they were sent.
• The hx-sync attribute is the official way to control concurrency: local (queue or cancel per element), global (queue or cancel across the page), or none (default).
• Using hx-sync="local cancel-previous" will cancel any pending request targeting the same element before sending a new one.
• Using hx-sync="local queue" will enqueue subsequent requests, ensuring they are processed sequentially.

Likely Explanation (but not guaranteed for your scenario)

If you fire rapid triggers on the same element without hx-sync, you might observe out‑of‑order updates: a later request that finishes quickly could overwrite the UI that was updated by an earlier, slower request. This is especially visible with outerHTML swaps, which replace the entire element and can discard event listeners added by the first response.

Practical Steps for Your Migration

1. Identify overlapping triggers. Look for elements that have multiple hx-get/hx-post attributes or hx-trigger that can fire in quick succession.
2. Decide on a strategy. Choose hx-sync="local cancel-previous" if you want the most recent user action to win, or hx-sync="local queue" if you need all responses applied in order.
3. Apply the attribute. Add hx-sync to the trigger element or to the hx-target element if you prefer to control concurrency at the target level.
4. Test with simulated delays. Use a server endpoint that sleeps for a few seconds before responding to confirm that the chosen hx-sync behavior matches expectations.
5. Verify DOM integrity. Inspect the Network tab to ensure that only the intended requests are sent and that the final DOM state reflects the desired order.

When to Consider Additional Measures

• If you need to preserve event listeners after an outerHTML swap, re‑attach them in a htmx:afterSwap event handler.
• For complex forms that may be submitted multiple times, consider disabling the submit button until the response returns.
• When multiple elements share the same hx-target and you need global coordination, use hx-sync="global cancel-previous" on the trigger.

Missing Diagnostic Detail

Could you confirm whether the overlapping triggers target the same element or different elements? Knowing this will help refine the hx-sync strategy (local vs. global) and ensure deterministic updates.