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
gf000 3 days 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.
spiffytech 3 days 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.
Jonovono 3 days 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.
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
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.
andersmurphy 3 days 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]
Thanks Carson. Although honestly it's pretty mid compared to what's actually possible in hypermedia.
The only reason I wheel it out is when people say you can't do X (often meaning react like things) with hypermedia.
Honestly, you could probably do it in HTMX if you are prepared to only use out of bounds swaps, morph and SSE. But, that approach has always felt second class, unfinished and against the grain. So stuff like that isn't done.
Always made me sad that you wrote idiomorph (thanks for sharing it with the world) but didn't make it part of HTMX. I guess HTMX 4 will change that?
AreShoesFeet000 3 days ago [-]
We live in a backend dictatorship after all don’t we?
bullen 3 days 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;
};
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 3 days 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.
recursivedoubts 3 days 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:
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 3 days ago [-]
I started w htmx and golang backend, and later switched to sveltekit since its just easier to build ui w these frameworks
ranger_danger 3 days 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.
evolve-maz 3 days 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.
wild_egg 3 days 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_danger 3 days 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.
test1072 3 days ago [-]
No idea much about htmx but can we write custom extension something to add to htmx ?
Rendered at 19:48:25 GMT+0000 (Coordinated Universal Time) with Vercel.
https://four.htmx.org/htmx-4/#built-in-streaming-response-su...
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 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.
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.
https://github.com/StreamUI/hyperstar
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.
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
The only reason I wheel it out is when people say you can't do X (often meaning react like things) with hypermedia.
Honestly, you could probably do it in HTMX if you are prepared to only use out of bounds swaps, morph and SSE. But, that approach has always felt second class, unfinished and against the grain. So stuff like that isn't done.
Always made me sad that you wrote idiomorph (thanks for sharing it with the world) but didn't make it part of HTMX. I guess HTMX 4 will change that?
> If you need bi-directional communication, then you should consider using WebSockets instead.
Or you just do a HTTP request?
https://htmx.org/attributes/hx-swap/ https://htmx.org/attributes/hx-swap-oob/ https://htmx.org/attributes/hx-target/
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/
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.
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.
What use case do you have in mind?