5 ms·

I think where htmx would differ in your example is that it would not maintain the state of the list of cars in javascript, but would instead keep that state in

I think where htmx would differ in your example is that it would not maintain the state of the list of cars in javascript, but would instead keep that state in the html, and the server. I think the button might be something like this, I'm borrowing from their [delete row example](https://htmx.org/examples/delete-row/ https://htmx.org/examples/delete-row/). `<button hx-confirm="Really delete {{item.name}}?" hx-target="closest tr" hx-swap="outerHTML swap:1s" hx-delete="<the url>">Delete this car</button>` In terms of your update example, yeah I think that's what htmx would do, just on the server, and returning rendered html.

budafish 3y ago
Also if you didn't want to do a hx-confirm, you could pop up a separate modal on button press. And then when the delete is pressed in the modal use a hx-target to update the specific row.
mg 3y ago
Hmm.. I don't think you can simplify their example to just that one line. For example, where is the url which is supposed to be requested to delete the item on the server.
- naasking 3y ago
  Add the hx-post="[url]" attribute.
  - monknomo 3y ago
    good point, though I think hx-delete matches better
- monknomo 3y ago
  You are right! There would need to be more. but also, I'm not trying to provide a complete solution, just a direction to look in.
kodapoda 3y ago
Beyond these very limited examples I just cannot see any appeal of HTMX... The real world large web apps have a ton of state that needs to be updated, UI elements that need to be swapped, multiple remote calls that need to be made on these actions. Why would you push all of that to the BE? A simple click is almost never just "delete a row": you need to update the row count in the UI, validate whether it's the last row and therefore can't be deleted, send a log message that pulls data from user state (are you going to construct this state in the API handler every time a row is deleted?), update a heavy graph that shows a visualization of the data in rows, etc... Maybe some very basic websites can survive with HTMX but that's incredibly not future-proof.
- recursivedoubts 3y ago
  in htmx you would do all that through a single action and target the area necessary to update if you had something like a count that was outside that area you could use an event, an out of band swap or just expand the target. we also have morph-based swaps that make it possible to retain more UI state while expanding the target area, if you'd like if you have some sort of visualization, you'd recompute it server side and stream it back, or use events to trigger an update adam james has done some cool stuff w/clojure and htmx visualizations: https://twitter.com/RustyVermeer/status/1701048955105391044 https://twitter.com/RustyVermeer/status/1701048955105391044 a little bit of hypermedia-friendly scripting can go a long way: https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ you are correct that htmx isn't for every application, but it can likely pull off a lot more than you think, and at much lower complexity levels than reactive options, which has been borne out by real world experience: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ as far as htmx being future-proof, I would point to it's predecessor, intercooler.js, which was released in 2013 and is still actively supported, simply because the code isn't hard to deal with. you could probably figure out and maintain htmx.js in a day or two, as a good JavaScript developer, something that can't be said for most other javascript frameworks.
  - dragonelite 3y ago

budafish 3y ago

Also if you didn't want to do a hx-confirm, you could pop up a separate modal on button press. And then when the delete is pressed in the modal use a hx-target to update the specific row.

mg 3y ago

Hmm.. I don't think you can simplify their example to just that one line. For example, where is the url which is supposed to be requested to delete the item on the server.

naasking 3y ago
Add the hx-post="[url]" attribute.
- monknomo 3y ago
  good point, though I think hx-delete matches better
monknomo 3y ago
You are right! There would need to be more. but also, I'm not trying to provide a complete solution, just a direction to look in.

kodapoda 3y ago

Beyond these very limited examples I just cannot see any appeal of HTMX... The real world large web apps have a ton of state that needs to be updated, UI elements that need to be swapped, multiple remote calls that need to be made on these actions. Why would you push all of that to the BE? A simple click is almost never just "delete a row": you need to update the row count in the UI, validate whether it's the last row and therefore can't be deleted, send a log message that pulls data from user state (are you going to construct this state in the API handler every time a row is deleted?), update a heavy graph that shows a visualization of the data in rows, etc... Maybe some very basic websites can survive with HTMX but that's incredibly not future-proof.

recursivedoubts 3y ago
in htmx you would do all that through a single action and target the area necessary to update if you had something like a count that was outside that area you could use an event, an out of band swap or just expand the target. we also have morph-based swaps that make it possible to retain more UI state while expanding the target area, if you'd like if you have some sort of visualization, you'd recompute it server side and stream it back, or use events to trigger an update adam james has done some cool stuff w/clojure and htmx visualizations: https://twitter.com/RustyVermeer/status/1701048955105391044 https://twitter.com/RustyVermeer/status/1701048955105391044 a little bit of hypermedia-friendly scripting can go a long way: https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ you are correct that htmx isn't for every application, but it can likely pull off a lot more than you think, and at much lower complexity levels than reactive options, which has been borne out by real world experience: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ as far as htmx being future-proof, I would point to it's predecessor, intercooler.js, which was released in 2013 and is still actively supported, simply because the code isn't hard to deal with. you could probably figure out and maintain htmx.js in a day or two, as a good JavaScript developer, something that can't be said for most other javascript frameworks.
- dragonelite 3y ago