Hacker News Reader

Comment by devnull3 | Hacker News Reader

This should be trivial with the HTMX alternative: datastar [1]

In datastar the "Out Of Band" updates is a first class notion.

Unrelated: datastar doesn't use a two-way connection for interaction <-> updates. It uses two unconnected one-way channels: a long-lived long-lived SSE for updates, and new HTTP requests for interaction.

I didn't see guidance in the docs for routing one tab's interaction events to the backend process managing that tab's SSE. What's the recommend practice? A global, cross-server event bus? Sticky sessions with no multiprocessing, and an in-process event bus?

If a user opened the same page in two tabs, how should a datastar backend know which tab's SSE to tie an interaction event to?

It appears to be a SSE channel for each event stream returned, not one channel for all subsequent updates. So a PHP backend for instance could batch all the updates from one request, would open a new SSE channel, send the updates over that, then close it. With an in-process server like swoole or most things not PHP, you could presumably reuse the channel across requests in whatever framework-specific way makes that happen. Would probably need sticky sessions in any scaled-out deployment.

This is just what I can glean from the docs, I've never actually used datastar myself.

With DS (and HTMX) the backend is the source of truth. In the context of the blog post, the state will be made-up of: step no, file content, file path, etc. This can be stored against the session ID in a database.

So when opened on a different tab, the backend would do authentication and render the page depending on the store state.

In general, the backend must always compare the incoming state/request with stored state. E.g the current step is step 2 but the client can forces it to go to step 4 by manipulating the URL.

DS v1.0 now supports non-SSE (i.e. simple request/response interaction as well) [1]. This is done by setting appropriate content-type header.

[1] https://data-star.dev/reference/actions#response-handling

HTMX has out of band updates too [0], what's the differentiator?

[0] https://htmx.org/attributes/hx-swap-oob/

In DS, with SSE you can paint different parts of the page with ease. So in this case, it can update <form> and <label> separately. So instead of one update the backend fires 2. There is not separate marker or indicator for OOB.

I think it is best seen in examples on DS website.

Neat, I'll give DS a go.

HTMX also has the option of using SSE with an extension [0]. I've used this to update the notifications tray for example. You could probably do it for OPs example too.

[0] https://htmx.org/extensions/sse/

Doesn't datastar require an async backend? I prefer Django without async.

You still get a lot with a sync backend! Here I show Datastar using Flask: https://www.youtube.com/watch?v=W7kHYIrI99A

Not really. DS v1.0 has HTMX like request/response option as well.

You might need async if there are lot of concurrent users and each of them using long duration SSE. However, this is not DS specific.

Reply on news.ycombinator.com