HN Explorer

7 comments

[ 5.9 ms ] story [ 27.4 ms ] thread
nasretdinov
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
gf000
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.

bullen
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?

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

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