htmx: Server Sent Event (SSE) Extension
(htmx.org)69 points by tosh a day ago
69 points by tosh a day ago
we are actually considering moving it out again because we also recently picked up a great, reworked websocket extension, and don't want to necessarily privilege one way of doing this sort of programming over the other
what is going to change is that htmx will ship with the "core" extensions (ws, sse, optimistic responses, etc.) as a single release, so they can all be composed easily together and are tested together
we'll see, still in alpha
I have given a try to data-star that is pretty similar to htmx, and it already had SSE support. (But I think it is a bit more complete solution to the problem - giving lightweight primitives for client-side interactivity)
I think it's (referring to both) a pretty nice framework, though it does require a bit of mental "undoing" if you have worked a lot with SPAs.
The part that really sets Datastar apart for me is it holds client-side variables which are included in all requests. So I no longer have to think about piping & preserving view state when the DOM gets patched.
It's also neat how they use SSE for short-lived streams. Need a response to delete + add something? That's just two SSE events and then the stream closes. It's not a special case, it's a first-class mechanism.
Very happy with Datastar so far.
I've been playing around with making a little framework for building these server driven UIs in a way with a syntax more like SPAs. I originally was using datastar behind the scenes, but decided to just write my own version of it, much easier to work with.
As a backend engineer I really like where all of this is going. In many many cases you do not need anything beyond what HTMX provides, and it makes the build and testing process so much simpler, and faster too
This levels concept resonates with me: https://www.lorenstew.art/blog/progressive-complexity-manife...
There are cases where you need more than htmx / datastar, but i like the explicit calling out of when these boundaries occur (e.g. you've exceeded what "islands" can give you), and i like the gravitational pull to lower levels.
The limitations of HTMX are not the same as the limitations of Datastar. Datastar is a whole other beast with only a few at most vestigial similarities to HTMX.
You can't do virtual scroll over a billion checkboxes in HTMX (I've yet to see anyone manage in react for that matter either), yet you can do it easily in Datastar. [1]
We live in a backend dictatorship after all don’t we?
What is the advantage over just using this:
var source = new EventSource('pull?name=one');
source.onmessage = function (event) {
document.getElementById('events').innerHTML += event.data;
};
> If you need bi-directional communication, then you should consider using WebSockets instead.
Or you just do a HTTP request?
HTMX can do much more than just innerHTML swap.
https://htmx.org/attributes/hx-swap/ https://htmx.org/attributes/hx-swap-oob/ https://htmx.org/attributes/hx-target/
I mean you're not wrong: end of the day htmx is just some javascript written on top of standard vanilla javascript apis. It tries to handle things in a more html-centric, attributes-driven manner than script-oriented approaches do, but it's nothing too complicated
check out fixi for our ultra-minimalist take on the idea:
https://github.com/bigskysoftware/fixi
Or, for extreme minimalisim, htmz, which repurposes iframes for a similar idea:
While no doubt all these changes are for the best I have to wonder how many are using htmx for the same reasons as I do. It’s simple. I don’t need much functionality. I don’t want to spend time in frontend work so any changes are just a pain and only risk losing business. Htmx 1 and Django are working great for me and I don’t need to change for some time.
I started w htmx and golang backend, and later switched to sveltekit since its just easier to build ui w these frameworks
I know I will get downvoted for this and people will just say "you're doing it wrong" or "the library wasn't designed for that" but I still think it would be really helpful for some people if the source of the data to swap out could be retrieved from parsing the response data as JSON and grabbing a certain named key.
Yes one can add a callback function to parse the data as JSON, do error handling etc. and then swap the text/HTML, but having that built in to a hx-foo attribute would be a lot easier.
Htmx has events you can listen to like htmx after response. You can think of it almost like a middleware. After the response comes in, your callback is triggered and you can make the callback look up some attribute given the calling parents attribute that you might call hx-json-key.
Yes you have to add this yourself, but you only need to add one js function once and be done with it.
I've used the callback pattern for custom error handling for all hx responses.
Re-using existing API calls that I can't change, where I want to replace the text of an html element with the text from a specific key in a json response.
FWIW, this will be part of the core library in the next version instead of a separate extension.
https://four.htmx.org/htmx-4/#built-in-streaming-response-su...