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

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

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.

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?

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