4 ms·

I wonder what to think of htmx. Their primary example is this: <button hx-post="/clicked" hx-swap="outerHTML"> Click Me </button> But that is

by mg 3y ago

I wonder what to think of htmx. Their primary example is this: <button hx-post="/clicked" hx-swap="outerHTML"> Click Me </button> But that is rarely what I want to do when a button is clicked. My typical example would be I have list of - say - cars, and each car provides a button to delete it: <button onclick="carList.deleteItem(this)"> Delete this car </button> And then in deleteItem(), I typically: let item=getItem(e); if (!confirm(`Really delete ${item['name']}?`)) return; let item_id=getItemId(e); items.splice(item_id,1); document.getElementById('items').innerHTML = template(items); Where "template" is a handlebars template. Would htmx have anything to say about this?

kitd 3y ago
Here's Htmx's "Delete a row" example, which I think is what you're after: https://htmx.org/examples/delete-row/ https://htmx.org/examples/delete-row/ The Examples page in general shows most typical use cases.
monknomo 3y ago
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
stavros 3y ago
You make the delete button load the /delete/ID URL, and return the fragment of the entire car list, to replace the existing fragment.
pier25 3y ago
So the button would call a URL that would delete the car, and return the full list of cars to be replaced.
dll 3y ago
You'd use the hx-delete attribute and have a server side handler that responded to that by deleting the item & returning a new list of items. You can see an example of that approach (with Rust + Actix Web) here that I'm currently working on (the partial to list todo items is in templates, and you can follow the delete link to the relevant handler in routes/todo/delete.rs): https://github.com/welshdave/actix-htmx/tree/main/examples/todo https://github.com/welshdave/actix-htmx/tree/main/examples/t...
stmblast 3y ago
Normally I attach the ID to any newly created item via a templating engine so that when you use `hx-delete` to send a DELETE request, you'll be able to easily refer to what item you want to delete.
BiteCode_dev 3y ago
Something like this: <button hx-delete="/car/{{car['id']}}" hx-swap="delete" hx-target="closest .carcontainer" >Delete this car</button> When you come to HTMX, it's normal to wonder about those kind of things, especially if you have being learning web dev post JSON era. If this is your case, I'm writing a series of 5 tutorials on HTMX with this in mind: https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1 https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1
- mg 3y ago
  This is approaching the code size of the vanilla js version. And it does not have the confirmation modal. If there would be additional computational logic involved (say calculating how many rides this car has done this year so far to say "Really delete this car? It delivered 124 rides this year.") - would you also cram all of that into the button element? What I am trying to say: I don't see which real world use cases are tackled by htmx. I usually don't have a use case as simple as "When element X is clicked, load url Y and replace element Z with it".
  - npilk 3y ago
    From an htmx perspective, you would probably calculate things like that on the server. So the row delete button might have an hx-get="<delete-confirm-url>" that returns an HTML snippet with your modal content ("Really delete this car?") and then the button in that modal would have hx-delete="<delete-url>". Of course you can still add vanilla JS with htmx, and/or send the car.rides_delivered value from your model as part of the initial page load, etc. You don't have to do everything with the hx- attributes. In my opinion htmx is excellent when you have a state that can be easily managed on the server, because it makes it simple to get an interactive SPA feel while still keeping state on the server. I think a lot of the htmx fan base would argue that most web apps don't need to manage their state client-side and therefore don't need all the overhead of React, etc. But of course htmx isn't a cure-all. You can check out the writing on htmx.org if you're curious to hear more of the author's perspective and goals.
  - BiteCode_dev 3y ago

by mg 3y ago

kitd 3y ago

Here's Htmx's "Delete a row" example, which I think is what you're after: https://htmx.org/examples/delete-row/ https://htmx.org/examples/delete-row/ The Examples page in general shows most typical use cases.

monknomo 3y ago

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

stavros 3y ago

You make the delete button load the /delete/ID URL, and return the fragment of the entire car list, to replace the existing fragment.

pier25 3y ago

So the button would call a URL that would delete the car, and return the full list of cars to be replaced.

dll 3y ago

You'd use the hx-delete attribute and have a server side handler that responded to that by deleting the item & returning a new list of items. You can see an example of that approach (with Rust + Actix Web) here that I'm currently working on (the partial to list todo items is in templates, and you can follow the delete link to the relevant handler in routes/todo/delete.rs): https://github.com/welshdave/actix-htmx/tree/main/examples/todo https://github.com/welshdave/actix-htmx/tree/main/examples/t...

stmblast 3y ago

Normally I attach the ID to any newly created item via a templating engine so that when you use `hx-delete` to send a DELETE request, you'll be able to easily refer to what item you want to delete.

BiteCode_dev 3y ago

Something like this: <button hx-delete="/car/{{car['id']}}" hx-swap="delete" hx-target="closest .carcontainer" >Delete this car</button> When you come to HTMX, it's normal to wonder about those kind of things, especially if you have being learning web dev post JSON era. If this is your case, I'm writing a series of 5 tutorials on HTMX with this in mind: https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1 https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1

mg 3y ago
This is approaching the code size of the vanilla js version. And it does not have the confirmation modal. If there would be additional computational logic involved (say calculating how many rides this car has done this year so far to say "Really delete this car? It delivered 124 rides this year.") - would you also cram all of that into the button element? What I am trying to say: I don't see which real world use cases are tackled by htmx. I usually don't have a use case as simple as "When element X is clicked, load url Y and replace element Z with it".
- npilk 3y ago
  From an htmx perspective, you would probably calculate things like that on the server. So the row delete button might have an hx-get="<delete-confirm-url>" that returns an HTML snippet with your modal content ("Really delete this car?") and then the button in that modal would have hx-delete="<delete-url>". Of course you can still add vanilla JS with htmx, and/or send the car.rides_delivered value from your model as part of the initial page load, etc. You don't have to do everything with the hx- attributes. In my opinion htmx is excellent when you have a state that can be easily managed on the server, because it makes it simple to get an interactive SPA feel while still keeping state on the server. I think a lot of the htmx fan base would argue that most web apps don't need to manage their state client-side and therefore don't need all the overhead of React, etc. But of course htmx isn't a cure-all. You can check out the writing on htmx.org if you're curious to hear more of the author's perspective and goals.
- BiteCode_dev 3y ago