htmx-realtime

htmx Realtime

Use this skill when a page needs updates after initial render without full refresh. Choose the simplest transport that matches update frequency, direction, and operational cost.

Transport Decision

Do not start with WebSockets just because updates feel realtime. Polling is easier to operate and test when updates are infrequent.

Polling

Use polling for job status, notifications, progress panels, and dashboards where a short delay is acceptable.

• Keep the response small.
• Choose an interval based on business need, not impatience.
• Stop polling when the work is complete.
• Return a final fragment that removes or disables the polling trigger.
• Use server-side throttling or caching when many users poll the same state.
• Avoid polling hidden tabs or offscreen widgets unless the value justifies it.

Load Polling

Use load polling when each response decides whether another request should happen. It works well for background jobs because the server can stop the loop by returning the final state without the next trigger.

Keep the next trigger near the fragment that owns the state so a final replacement removes the loop.

Server-Sent Events

Use SSE when the server pushes one-way updates to the browser:

• notifications;
• progress messages;
• append-only activity feeds;
• operational status streams.

Typical htmx SSE extension shape:

<section hx-ext="sse" sse-connect="/events" sse-swap="message">
  <div id="events"></div>
</section>

Server responsibilities:

• authenticate the stream;
• send heartbeat comments or events when infrastructure requires it;
• close streams cleanly;
• format event payloads as trusted HTML fragments when htmx will swap them;
• document reconnect behavior.

WebSockets

Use WebSockets when the browser and server both send messages over a long-lived connection:

• chat;
• multiplayer or collaborative UI;
• live dashboards with user actions;
• bidirectional device or workflow control.

Typical htmx WebSocket extension shape:

<div hx-ext="ws" ws-connect="/socket">
  <form ws-send>
    <input name="message">
    <button type="submit">Send</button>
  </form>
  <div id="messages"></div>
</div>

Server messages should usually be HTML fragments with stable targets or out-of-band swaps. Keep message formats narrow and versionable.

State And Reconciliation

• The server should remain the source of truth for durable state.
• Messages should be idempotent or safely replaceable.
• Include resource identifiers in fragments or targets so late messages do not corrupt the wrong component.
• Decide how to handle disconnects: missed messages, reload, replay, or fetch current state.
• For optimistic UI over WebSockets, design rollback and server confirmation explicitly.

Operational Checks

• Does the deployment platform support long-lived connections?
• Are proxies configured for buffering, timeout, and upgrade behavior?
• Is authentication refreshed or rejected cleanly when sessions expire?
• Are connection counts bounded?
• Is backpressure handled when clients are slow?
• Are heartbeats and reconnects tested?

Security

• Authenticate streams and sockets just like normal endpoints.
• Enforce authorization per message, not only at connection time.
• Escape or sanitize user content before sending HTML fragments.
• Avoid putting secrets in client-visible stream messages.
• Review CSP and extension loading with htmx-security.

Testing Checklist

• Test initial connection and expected fragment updates.
• Test disconnect/reconnect behavior.
• Test expired or unauthorized sessions.
• Test malformed client messages for WebSockets.
• Test that final polling states stop further requests.
• Test multiple simultaneous clients when state is shared.

Avoid

• Do not use WebSockets for simple "check every few seconds" status.
• Do not leave infinite polling without a stop condition.
• Do not stream unescaped user content into HTML swaps.
• Do not assume all hosting providers treat SSE and WebSockets the same.
• Do not couple realtime messages to page structure that may change without tests.