Using htmx hx-trigger every for Simple Periodic Polling

Problem: Keeping a UI fragment fresh without a full reload

Many dashboards need to show slowly changing data—like a request count, a temperature reading, or a queue length—while avoiding the overhead of a full page refresh. Writing custom JavaScript timers and AJAX calls works, but it adds boilerplate and couples UI logic to the client side.

Thesis: htmx’s hx-trigger every modifier lets you declaratively schedule HTTP polling, so the browser automatically fetches updates and swaps the response into a target element.

How the modifier works

The hx-trigger attribute accepts a comma‑separated list of events. Adding every 2s (or any time value) creates an internal timer that starts after the element is initialized and fires the specified request repeatedly at that interval. When combined with hx-get (or hx-post), hx-target, and hx-swap, the response is inserted into the chosen DOM node without a page reload.

Worked example: live counter

Assume a simple endpoint /counter that returns the current count as plain text or a small HTML fragment.

<!-- Place this where you want the counter to appear -->
<div
  hx-get="/counter"
  hx-trigger="every 1s"
  hx-target="#counter-output"
  hx-swap="innerHTML"
></div>

<div id="counter-output">Loading…</div>

When the page loads, htmx starts a one‑second timer. Each tick it issues a GET request to /counter and replaces the contents of #counter-output with the response. Open the browser’s Network tab to see a steady stream of requests; the DevTools console will show no errors if the endpoint returns valid HTML/text.

Trade‑offs and limitations

• Latency: Data can be stale by up to the polling interval (e.g., up to 1 second in the example).
• Traffic: Each interval generates an HTTP request, which adds load compared to a persistent WebSocket connection.
• Server load: With many concurrent users, short intervals can overwhelm the backend; choose the interval based on acceptable staleness and server capacity.
• Error handling: If the endpoint returns malformed HTML, htmx may silently fail; inspect the response in the Network tab and watch for console warnings.

When to choose polling over WebSocket

Use hx-trigger every when:

• Updates are infrequent enough that a few seconds of staleness is acceptable.
• You already have a REST‑style endpoint that returns HTML or a fragment.
• You want to avoid managing WebSocket connections, heartbeats, and reconnection logic on the client.

For real‑time, low‑latency needs (e.g., chat, collaborative editing), a WebSocket or Server‑Sent Events approach remains preferable.

Actionable closing

Add the hx-trigger every attribute to any element that needs periodic refreshes, point it at a lightweight endpoint, and verify the behavior by watching the Network tab for regular requests and the target element for updates. Adjust the interval to balance freshness against server load, and you’ll have a working polling UI with minimal JavaScript.