5 ms·

> why use HTMX when it really seems like (a heavier) Datastar-lite? The reason to use htmx is that it has a simpler interface optimized for the majority use-ca

> why use HTMX when it really seems like (a heavier) Datastar-lite? The reason to use htmx is that it has a simpler interface optimized for the majority use-case. With htmx, you are largely tied to a request/reply paradigm. Something happens that triggers a request (e.g. user clicks a button, or some element scrolls into view), htmx sends the request, and then it processes the response. The htmx interface (`hx-get`, hx-trigger`) is optimized to make this paradigm extremely simple and concise to specify. Datastar's focus (last I checked) is on decoupling these two things. Events may stream to the client at any time, regardless of whether or not they were triggered by a specific action on the client, and they get processed by Datastar and have some effect on the page. htmx has affordances for listening to events (SEE extension, new fetch support) and for placing items arbitrarily on the page (out-of-band swaps) but if your use-case is a video game or a dashboard or something else where the updates are frequently uncorrelated with user actions, Datastar makes a lot of sense. It's a bit like driving a manual transmission. Delaney is fond of saying that there's no need for htmx when Datastar can technically do everything htmx can [0]. But I think this misses the point of what makes htmx so popular: most people's applications do fit within a largely request/reply paradigm, and using a library that assumes this paradigm is both simpler to implement and simpler to debug. As an htmx maintainer, I often encourage people to even use htmx less than they want to, because the request/reply paradigm is very powerful and the more you can adhere to browser's understanding of it, the more durable and maintainable your website will be [1]. [0] https://data-star.dev/essays/v1_and_beyond https://data-star.dev/essays/v1_and_beyond [1] https://unplannedobsolescence.com/blog/less-htmx-is-more/ https://unplannedobsolescence.com/blog/less-htmx-is-more/

andersmurphy 11mo ago
Why bother with v4 at all? If it dilutes that simpler interface? I think that even with req/resp morph leads to a simpler majority use case and that's what Turbo and Datastar have both shown. No?
- alexpetros 11mo ago
  > Why bother with v4 at all? If it dilutes that simpler interface? v4 makes almost no changes to the interface, other than to flip inheritance to be off by default. > I think that even with req/resp morph leads to a simpler majority use case and that's what Turbo and Datastar have both shown. No? Although you can use the idiomorph extension for htmx, I personally don't think idiomorph is simpler, because there's an algorithm choosing what parts of the page get replaced based on the server response; I prefer to specify exactly what parts of the page get replaced in much simpler terms, a CSS selector, with `hx-target`. Per [1] above, my style is minimize partial page responses wherever possible, so the ones that I do have are bespoke and replace a specific thing.
  - nchmy 11mo ago
    Are you aware that v4 is baking idiomorph into the core...?
    - alexpetros 11mo ago
      Yes! I expect that I will mostly be sticking to `hx-target` though, for the reasons stated above. My interest in htmx is more on the coarse-grained aspects of its interface, not the finer ones, which is a consistent theme in my writings about it [0]. [0] https://alexanderpetros.com/triptych/ https://alexanderpetros.com/triptych/
      - sudodevnull 11mo ago
        hey Alex, I hope you are well. Datastar has had direct support for req/rep of HTML, JS, JSON while still morphing for a quite a while. They allow you to go as coarse as you want. Give the size and ability to choose what plugins you actually need seems like Datastar is more in line with your wants at this point. Strange times.
    - deleted 11mo ago
      [deleted]
    - andersmurphy 11mo ago
nchmy 11mo ago
Respectfully, almost everything you said is just plain wrong. 1. Datastar supports req/reply just fine - be it via normal text/html responses, or SSE (0, 1, or infinity responses) https://data-star.dev/reference/actions#response-handling https://data-star.dev/reference/actions#response-handling. So, the crux of your argument is moot... Moreover, if htmx's real value is ajax request/response, then why are you introducing SSE as a first-class citizen now? 2. Datastar has data-on, and various other attributes, that allow for triggering far more actions than just backend requests, from far more (any) events. I'm glad to see that htmx is now following suit with hx-on, even if it is apparently limited in capabilities. 3. Datastar can do OOB-swaps just fine - that's literally the core functionality, via (their own, faster) idiomorph. 4. Its a misnomer that Datastar is for video games etc - again, as described above, it can do all of the simple things that that HTMX can do, and more. And, again, why is HTMX introducing SSE if its so apparently unnecessary and unwieldy? 5. What makes htmx popular is that it was the first library to make declarative fragment swapping easy. And Carson is just a god-tier marketer. Its nice to see that he's now realized that Delaney was on to something when he wanted to introduce all of these v4 features to HTMX 3 years ago, but was (fortunately for us happy users) forced to go make Datastar instead. 6. We havent even talked about one of the key features - declarative signals. Signals are justifiably taking over all of the JS frameworks and there's even an active proposal to make them part of the web platform. D* makes them simpler to use than any of them, and in a tiny package. I, Delaney, and all other D* users are grateful for HTMX opening this door. But I reiterate my original question - now that HTMX is becoming Datastar-lite, why not just use Datastar given that the powerful extras don't add any complexity and comes in a smaller package?
- alexpetros 11mo ago
  So here's the htmx example for click to edit: [0] <button hx-get="/contact/1/edit"> And here's the datastar one, edited for parity: [1] <button data-on:click="@get('/contact/1/edit')"> The htmx one is simpler. There's fewer mini-languages to learn and the API makes more assumptions about what you want. As you noted, Datastar has more generalized mechanisms that are certainly less clunky than htmx's if you lean heavily into more signals- or event-driven behavior, but for (what I believe to be) the majority use-case of a CRUD website, htmx's simpler interface is easier to implement and debug.(For example: you will see the response associated with the request in the browser network tab; I'm not sure if Datastar has a non-SSE mode to support that but it wouldn't be true for SSE.) To each their own. As for "well then why implement X, Y, or Z," as the OP notes, refactoring to use fetch() means you get them largely for free, without compromising the nice interface. So why not? [0] https://htmx.org/examples/click-to-edit/ https://htmx.org/examples/click-to-edit/ [1] https://data-star.dev/examples/click_to_edit https://data-star.dev/examples/click_to_edit

andersmurphy 11mo ago

Why bother with v4 at all? If it dilutes that simpler interface? I think that even with req/resp morph leads to a simpler majority use case and that's what Turbo and Datastar have both shown. No?

alexpetros 11mo ago
> Why bother with v4 at all? If it dilutes that simpler interface? v4 makes almost no changes to the interface, other than to flip inheritance to be off by default. > I think that even with req/resp morph leads to a simpler majority use case and that's what Turbo and Datastar have both shown. No? Although you can use the idiomorph extension for htmx, I personally don't think idiomorph is simpler, because there's an algorithm choosing what parts of the page get replaced based on the server response; I prefer to specify exactly what parts of the page get replaced in much simpler terms, a CSS selector, with `hx-target`. Per [1] above, my style is minimize partial page responses wherever possible, so the ones that I do have are bespoke and replace a specific thing.
- nchmy 11mo ago
  Are you aware that v4 is baking idiomorph into the core...?
  - alexpetros 11mo ago
    Yes! I expect that I will mostly be sticking to `hx-target` though, for the reasons stated above. My interest in htmx is more on the coarse-grained aspects of its interface, not the finer ones, which is a consistent theme in my writings about it [0]. [0] https://alexanderpetros.com/triptych/ https://alexanderpetros.com/triptych/
    - sudodevnull 11mo ago
      hey Alex, I hope you are well. Datastar has had direct support for req/rep of HTML, JS, JSON while still morphing for a quite a while. They allow you to go as coarse as you want. Give the size and ability to choose what plugins you actually need seems like Datastar is more in line with your wants at this point. Strange times.
  - deleted 11mo ago
    [deleted]
  - andersmurphy 11mo ago

nchmy 11mo ago

Respectfully, almost everything you said is just plain wrong. 1. Datastar supports req/reply just fine - be it via normal text/html responses, or SSE (0, 1, or infinity responses) https://data-star.dev/reference/actions#response-handling https://data-star.dev/reference/actions#response-handling. So, the crux of your argument is moot... Moreover, if htmx's real value is ajax request/response, then why are you introducing SSE as a first-class citizen now? 2. Datastar has data-on, and various other attributes, that allow for triggering far more actions than just backend requests, from far more (any) events. I'm glad to see that htmx is now following suit with hx-on, even if it is apparently limited in capabilities. 3. Datastar can do OOB-swaps just fine - that's literally the core functionality, via (their own, faster) idiomorph. 4. Its a misnomer that Datastar is for video games etc - again, as described above, it can do all of the simple things that that HTMX can do, and more. And, again, why is HTMX introducing SSE if its so apparently unnecessary and unwieldy? 5. What makes htmx popular is that it was the first library to make declarative fragment swapping easy. And Carson is just a god-tier marketer. Its nice to see that he's now realized that Delaney was on to something when he wanted to introduce all of these v4 features to HTMX 3 years ago, but was (fortunately for us happy users) forced to go make Datastar instead. 6. We havent even talked about one of the key features - declarative signals. Signals are justifiably taking over all of the JS frameworks and there's even an active proposal to make them part of the web platform. D* makes them simpler to use than any of them, and in a tiny package. I, Delaney, and all other D* users are grateful for HTMX opening this door. But I reiterate my original question - now that HTMX is becoming Datastar-lite, why not just use Datastar given that the powerful extras don't add any complexity and comes in a smaller package?

alexpetros 11mo ago
So here's the htmx example for click to edit: [0] <button hx-get="/contact/1/edit"> And here's the datastar one, edited for parity: [1] <button data-on:click="@get('/contact/1/edit')"> The htmx one is simpler. There's fewer mini-languages to learn and the API makes more assumptions about what you want. As you noted, Datastar has more generalized mechanisms that are certainly less clunky than htmx's if you lean heavily into more signals- or event-driven behavior, but for (what I believe to be) the majority use-case of a CRUD website, htmx's simpler interface is easier to implement and debug.(For example: you will see the response associated with the request in the browser network tab; I'm not sure if Datastar has a non-SSE mode to support that but it wouldn't be true for SSE.) To each their own. As for "well then why implement X, Y, or Z," as the OP notes, refactoring to use fetch() means you get them largely for free, without compromising the nice interface. So why not? [0] https://htmx.org/examples/click-to-edit/ https://htmx.org/examples/click-to-edit/ [1] https://data-star.dev/examples/click_to_edit https://data-star.dev/examples/click_to_edit