Hacker News Reader

Comment by DoesntMatter22 | Hacker News Reader

I used it on a project and I liked it but then I got into situations where I needed to pass a bunch of data back to the rendering page and it got really messy. The author says on the HTMX page that if you have this type of situation then HTMX is probably not the greatest fit.

Also as the project got larger there was a lot of issues with like "Wait, why isn't this loading? Oh man someone changed the name of a div I was using".

It's just not as clear when things stop working compared to most JS frameworks (which I hate, hence my interesting in HTMX).

I think for smaller projects it can be decent though.

View on HN

I think it would be a good idea in these situations (many cooks in the kitchen) to use a data attribute for each HTML element that uses HTMX, such as `data-htmx-id` to reference your elements instead of just using the `id` attribute (which already carries a lot of contextual baggage).

This would solve a couple potential issues:

- Identifying that the element is used for HTMX swaps

- Warning anyone that changing this attribute will break said HTMX swap

Sure, there are ways to work around it but it's just fairly brittle in that way, those measures help but on a large project people are going to be breaking things relatively frequently.

It sounds like in a bigger project a simple linter which checks that front end htmx and backend htmx tags have a match would solve that issue.

That would help, and certainly there are ways around it, but in the state of things right now it's gets ugly.

> I got into situations where I needed to pass a bunch of data back to the rendering page and it got really messy.

Could you not fetch that data separately from the patterns htmx provides and do some light parsing/rendering logic client-side?

That data needs to go to the page itself. Like you need to pull data that is on the main page and send that data down to the modal form submission. That is tricky. Is it doable? Yeah, it can be done but it's really ugly at that point.

The data was on the server at some point to begin with. How could it be tricky to put it somewhere just because $component is a modal?

How could it be tricky to have html loaded on multiple different parts of the page? Do you think it happens automatically? You have to track all of it. It's a pain. You need to embed hidden inputs then need to capture them, send them off, The modal stays on the screen but the underlying page needs to change behind it.

If you think that's easy then you'll love HTMX

You mean something like this? This does get a bit messier... https://htmx.org/docs/#oob_swaps

What you’re explaining didn’t make much sense. Would like to see an example where it’s messy because I haven’t seen one yet.

The ids changing is annoying tho!

I've found Alpine + HTMX a good combination for similar use cases, though I haven't tried to use them both with the same page elements and large collections of data. In my case Alpine localizes date times client side [1] and I intend to use Alpine to pass a bunch of data back to the rendering page. When you say HTMX got real messy, did you find something like Alpine conflicting with HTMX on the same elements?

[1]: https://pentacent.com/blog/date-time-inputs-with-alpine-js/

Reply on news.ycombinator.com