5 ms·

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

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

nchmy 11mo ago
That tiny difference is hardly a reason not to use datastar, especially when it brings SO MUCH more useful stuff - all in a smaller package. Moreover, the fact that Datastar is more generalized is actually better - HTMX has vastly more (non-standards-compliant) attributes that you need to learn. https://htmx.org/reference/ https://htmx.org/reference/ vs https://data-star.dev/reference/attributes https://data-star.dev/reference/attributes > 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. My first point was literally saying that it has non-SSE and linked to the docs. You're not even trying to be objective here... > So why not? Yes, I have no problem with these things being implemented in v4. In fact, celebrated it in my original post. I brought it all up because you were describing that all as needless complexity in Datastar, but now you're implementing it. Also, most of Datastar can be trivially disabled/unbundled because its nearly all plugins. That is largely not the case for HTMX. Thus far, you've simply strongly confirmed my initial hunch that HTMX v4 is unnecessary compared to Datastar.
andersmurphy 11mo ago
Less characters is not simple that's easy. Which is why HTMX is having to bolt on more gubbins. Because, although it's less characters to type its fundamentally complected and therefore less composable. I'm sure you've already warched it but if you haven't I'd recommend Rich Hickey's talk Simple made Easy.
- yawaramin 11mo ago
  I don't think the takeaway from Hickey's talk is just a blind 'simple is always good, easy is always bad'. It's actually important to offer 'easy' affordances in some cases. Htmx operates at a specific level of abstraction. This abstraction has been carefully chosen to work to create apps in a certain way. It's like a shortcut for creating a simple kind of hypermedia-driven app with some easy conveniences. I think this is a significant and important point in the design space.
  - sudodevnull 11mo ago
    The power in Datastar is YOU get to choose what plugins you use to build the API you what... want data-get, it's a few lines away from being yours! You can rebuild all of HTMX in Datastar, not the other way around. https://data-star.dev/examples/custom_plugin https://data-star.dev/examples/custom_plugin is a great intro
    - yawaramin 11mo ago
      Yes, and the htmx philosophy is that it gives you some default functionality out of the box, it doesn't just hand you a bunch of building blocks and ask you to put everything together yourself. Both are valid approaches. I don't know why one side always has to come in and try to put down the other. Without htmx, there is no Datastar.
      - sudodevnull 11mo ago
        You are right! without HTMX 1 and the choices for future dev there would be no Datastar! If you think having a full framework while still allowing super easy way to make whatever API as you see fit is putting someone down, idk, ngmi.
nymanjon 11mo ago
HTMZ-BE: <a id="contact1" href="/contact/1/edit" role="button">Edit</a> Hhhmmm..., that's more verbose than both :-(

nchmy 11mo ago

That tiny difference is hardly a reason not to use datastar, especially when it brings SO MUCH more useful stuff - all in a smaller package. Moreover, the fact that Datastar is more generalized is actually better - HTMX has vastly more (non-standards-compliant) attributes that you need to learn. https://htmx.org/reference/ https://htmx.org/reference/ vs https://data-star.dev/reference/attributes https://data-star.dev/reference/attributes > 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. My first point was literally saying that it has non-SSE and linked to the docs. You're not even trying to be objective here... > So why not? Yes, I have no problem with these things being implemented in v4. In fact, celebrated it in my original post. I brought it all up because you were describing that all as needless complexity in Datastar, but now you're implementing it. Also, most of Datastar can be trivially disabled/unbundled because its nearly all plugins. That is largely not the case for HTMX. Thus far, you've simply strongly confirmed my initial hunch that HTMX v4 is unnecessary compared to Datastar.

andersmurphy 11mo ago

Less characters is not simple that's easy. Which is why HTMX is having to bolt on more gubbins. Because, although it's less characters to type its fundamentally complected and therefore less composable. I'm sure you've already warched it but if you haven't I'd recommend Rich Hickey's talk Simple made Easy.

yawaramin 11mo ago
I don't think the takeaway from Hickey's talk is just a blind 'simple is always good, easy is always bad'. It's actually important to offer 'easy' affordances in some cases. Htmx operates at a specific level of abstraction. This abstraction has been carefully chosen to work to create apps in a certain way. It's like a shortcut for creating a simple kind of hypermedia-driven app with some easy conveniences. I think this is a significant and important point in the design space.
- sudodevnull 11mo ago
  The power in Datastar is YOU get to choose what plugins you use to build the API you what... want data-get, it's a few lines away from being yours! You can rebuild all of HTMX in Datastar, not the other way around. https://data-star.dev/examples/custom_plugin https://data-star.dev/examples/custom_plugin is a great intro
  - yawaramin 11mo ago
    Yes, and the htmx philosophy is that it gives you some default functionality out of the box, it doesn't just hand you a bunch of building blocks and ask you to put everything together yourself. Both are valid approaches. I don't know why one side always has to come in and try to put down the other. Without htmx, there is no Datastar.
    - sudodevnull 11mo ago
      You are right! without HTMX 1 and the choices for future dev there would be no Datastar! If you think having a full framework while still allowing super easy way to make whatever API as you see fit is putting someone down, idk, ngmi.

nymanjon 11mo ago

HTMZ-BE: <a id="contact1" href="/contact/1/edit" role="button">Edit</a> Hhhmmm..., that's more verbose than both :-(