UX is broken for streaming HTML #2747
Comments
|
Unless I misunderstand what you’re trying to do, a Streaming HTML workflow is definitely possible with htmx as Kitten implements it on top of htmx using htmx and htmx-ws. I’m not sure if what we mean by “streaming” is the same thing but I don’t see how you could do this with regular htmx without WebSockets. In any case, in case you’re interested in how I implemented it in Kitten, here’s a good starting off point: |
|
I don't think htmx is the right tool for this job, unless you just send the complete "app shell" in the first response and then the periodic updates via the sse or ws extensions. Though I also suspect you're doing something wrong with regards to streaming. Anyway, you might consider the declarative shadow dom api, which can allow for something like what you've described without any JavaScript at all. https://lamplightdev.com/blog/2024/01/10/streaming-html-out-of-order-without-javascript/ |
Consider a backend that streams results to a frontend as they are available — e.g. one result every 100 milliseconds and 1000 results in total are sent. So, this example backend will immediately respond with
<html><body><ol>and every 100 milliseconds a result of the form<li><a href="todo">result n</a></li>will be sent over the open HTTP connection. This will continue for 100 seconds, ie. after 1000 results are sent. Finally, the backend sends</ol></body></html>and closes the connection.All browsers will display these results incrementally; as they come in. The user will thus see the first result within 100 milliseconds, and after one second the user will have ten results to consider. If, however, HTMX is used for this endpoint with e.g.
hx-boost, then nothing at all will be displayed until 100 seconds have passed (after all results have been sent by the backend and the connection has been closed). This essentially breaks web pages that are too slow to deliver the final byte to the client fast enough, as HTMX currently waits for the connection to be closed before displaying anything at all. This impacts slow connections as well, thereby hurting the responsiveness of HTMX on e.g. mobile connections.A feature PR was opened (#2101) which was unfortunately rejected by a maintainer of HTMX. An issue has been opened (#1911) which suggests that this is a feature that HTMX should have. I'm creating this issue because I think it's reasonable to consider this a bug in HTMX. A user adding a
hx-boostattribute to anatag should expect to see the same result as if there were no such attribute, but in the above case the result is radically different (it goes from usable to unusable).I'm opening this issue to discuss my stance above. I think streaming HTML is the most natural and simple way to deliver responses in a streaming fashion to a client while avoiding unnecessary Javascript libraries and frameworks, and I think it's a shame that it doesn't work with HTMX. There may be something I'm missing, however, in which case I'd like to have a discussion about it.
The text was updated successfully, but these errors were encountered: