htmx: Server Sent Event (SSE) Extension

by tosh • 6 months ago

71 26 6 months ago

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

CraigJPerry• 6 months ago

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.

andersmurphy2• 6 months ago

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]

[1] https://checkboxes.andersmurphy.com

AreShoesFeet000• 6 months ago

We live in a backend dictatorship after all don’t we?

gf000• 6 months ago

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.

Jonovono2• 6 months ago

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.

https://github.com/StreamUI/hyperstar

jadbox• 5 months ago

Hey I read over hyperstar and enjoy the whole minimal interface for syncing server state. Please do continue working on this and announce when it graduates from beta phase :)

spiffytech• 6 months ago

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.

wild_egg2• 6 months ago

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...

recursivedoubts4• 6 months 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

bullen• 6 months ago

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;
  };

http://talk.rupy.se/event.html

If you need bi-directional communication, then you should consider using WebSockets instead.

Or you just do a HTTP request?

adontz• 6 months ago

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/

anamexis• 6 months ago

Everything HTMX does could be "just" done using JS - this is self-evident. The whole point of HTMX is to enable features like this directly in HTML.

infamia• 6 months ago

If you do that you'll reset browser state with whatever you're replacing. For example things like scroll position, if the user opened an accordion, etc. would all be lost.

recursivedoubts4• 6 months ago

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:

https://leanrada.com/htmz/

ranger_danger2• 6 months ago

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.

test1072• 6 months ago

No idea much about htmx but can we write custom extension something to add to htmx ?

wild_egg2• 6 months ago

I'm really struggling to think of a scenario where I would want to do something like that.

What use case do you have in mind?

ranger_danger2• 6 months ago

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.

evolve-maz• 6 months ago

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.

mrits• 6 months ago

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.

diamondfist25• 6 months ago

I started w htmx and golang backend, and later switched to sveltekit since its just easier to build ui w these frameworks

htmx: Server Sent Event (SSE) Extension

Related Stories