8 ms·

I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out

I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right. The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form with some large select lists as well as the response of results became noticeable laggy when there was more than a half dozen results. I ended up switching to Alpine Ajax (https://alpine-ajax.js.org/ https://alpine-ajax.js.org/) and pulled the form out of the response and just used a local x-data on it to track the state. This greatly reduced the HTML I needed to send back to just the list of results. I did make the form a bit more complicated but the experience felt a lot snappier. Both versions just synced the form state from the URL and kept the initial render as full HTML from the server. I found that Alpine + Alpine Ajax was SMALLER than HTMX 4 even though (in my opinion) it offers a lot more features in a more approachable and intuitive way if you need to do interactivity and don’t want to trigger a request just to toggle some classes or attributes. Of course you can use both together (I started down that road) but you are mixing worlds and making the bundle size bigger at the same time. I still like HTMX and will probably use it again. I just found that with an interactive experience like a product listing page, where the HTML response was quite large/expensive to fetch, it wasn’t the best choice for that.

inigyou 2mo ago
have a look at https://segor.de/ https://segor.de/ - it just downloads 2MB of product listing data (pre-dating JSON!) and then does all filtering client-side
- benbristow 2mo ago
  [dead]
brabel 2mo ago
You swapped out HTMX because you couldn’t figure out how to load a list of items gradually instead of all at once??
- tclancy 2mo ago
  Want to help rather than throw tomatoes?
  - brabel 2mo ago
    It was a genuine question. I’ve implemented infinite scrolling in HTMX and it’s quite easy, another commenter posted an example from the HTMX docs and it’s a couple of lines of html.
    - zx8080 2mo ago
      No worse thing for ux as the infinite scroll. As it breaks the native cmd-f/ctrl-f page search and makes loading progressively slow.
      - brabel 2mo ago
        It doesn't do such thing at all, unless you think it's acceptable to load EVERYTHING in HTML, hide it, and do front-end search. Which would be completely nuts to do for things where infinite scroll is used.
        zx8080 2mo ago
        It's a blatant lie and bullshit. A github MR can be 5Mb size and my laptop has 64Gb RAM (swappable 3x of that to SSD if really needed). There's NO need for progressive loading there. Another example is filtered goods at the local electronics store webfront. Progressive loading without ability to go directly to page 7 wastes my time if I know that what I need is there as each load of 10 items takes time. But of course this pattern increases some shitty OKR in time-spent-on-website. Hate this.
- Capricorn2481 2mo ago
  Wouldn't constantly loading new items into a select form be super annoying? Can HTML even keep a select input open when new items are added?
dsego 2mo ago
You can always make the server-side render partials based on a request header. https://github.com/dsego/ssr-playground/blob/main/src/server.js#L61-L74 https://github.com/dsego/ssr-playground/blob/main/src/server...
- james2doyle 2mo ago
  That is what I did. I was using Astro which has full support for partial HTML via the router
  - dsego 2mo ago
    I think I understand now, even the partial required submitting everything to the server, which can be skipped if you can have interactivity without unnecessary requests.
    - james2doyle 2mo ago
      Exactly. The partial response was 100kb-200kb of HTML + the backend query time. Of course, depending on your filters. But a large chunk of that was just sending down the form on the left side, which I already had on page load, so that penalty was real. It was only the right side results of the experience that needed to be refetched when the form changed. But in HTMX, you are expected to just send the whole dang thing back for every change. Makes sense for a like-button, a dialog, or even a classic form submission. My refactor cut the HTML response by about 70kb and that made a big difference. The form became fully static and I had a simple Alpine data component that would just sync that state with the URL. Still used a GET on the form and still used the same partial endpoint. Just way less HTML to wait for.
      - WD-42 2mo ago
        Why are you expected to send down the whole thing? Maybe I’m missing something, but when you send the request from the form the response is just a partial of the results on the right hand side, using hx-target to specify some div instead of replacing the form. Form just stays there?
bee_rider 2mo ago
AJAX is old tech though, using stuff that worked in the year 2000 is cheating in 2026. You are supposed to make the site slow and bloated for some reason.
- james2doyle 2mo ago
  It isn’t literally AJAX. Just a catchy name. It is just a fetch wrapper that mimics the $get, $post, etc. API
papanoah 2mo ago
Is there a reason why you don't have an endpoint + template that renders only the result list. The form could be separate thing and issue a form submit request with all the selected filters? Seems better than rendering the whole page. You could even display a loader while the results are loading, and swap the list html element on success.
- james2doyle 2mo ago
  That is what I ended up doing but once I did that, I had a hell of a time getting that dynamic form working well with just the HTMX primitives. I even tried to do two different partials that would be fetched when I needed each one to rerender. The gist of what I was saying was that once I had a more complicated experience, the benefits of just fetching a fresh partial each time started to dwindle. The HTML response grew, I needed a bunch of inline handlers to patch over some state issues, as well as the complexity of the template, just started to be too much. Really it was the Alpine part that I was missing. Simple class toggles, easy way to toggle aria attributes, show/hide for elements, and reactive/computed values, were the things I needed to get the results the client wanted. If I was building a simple search input + results, I would use HTMX all day. These forum people make it work and that seems like a great use case. But it just didn’t fit with a more sophisticated form that had dynamic options plus a large results display and the burden of a slower query to just get the data.
nine_k 2mo ago
Despite the fact that HTMX is a good solution in many cases, it's not the best solution in all cases. Ditto for React, and for any technology actually. Planning and consideration are always required, if you care about the end result.
- james2doyle 2mo ago
  Yeah, exactly. People seem to think I was holding it wrong. Maybe! But I gave HTMX an honest try. Another team would have just done a whole React thing, no HATEOAS, boatload of JS, and a bunch more memory. I will likely use HTMX again for something when I think it makes sense. Maybe once the 4.0 beta is over though
sequoia 2mo ago
I can't really understand what you're describing. You have form on left & results on right, but you're requesting the new form state & re-rendering the form HTML on each request? Why? My naive understanding is that you could use something like hx-target to have the response to the form submissions update only the results area & the form should not need rerendered at all. Why does the form need rerendered on a per request basis? HTML/Browser already tracks the current form state.
- james2doyle 2mo ago
  Because the form changed based on the selections you made. Like facet search. Say you have a clothing store listing page and you filter for only "Shirts". Well, the filter that has "Material" might remove (or disable) the option for "Denim" because that is only for "Pants". So that state needs to be computed some where. My thought was, "Ok, refetch the whole thing with the updated options within the form (disable options that can’t be combined together) + the product results for those filters". But that was just a lot of HTML to ask for after each change. So decoupling it so that the form never refetched, just the results, made it a lot snappier. But you still have the form state issue where you want to update the options based on selections. So the form became a little Alpine data component and the results stayed as an HTML partial.
  - sequoia 2mo ago
    Ah OK, so you had a level of dynamic behaviour in the form itself that warranted an applet/data component for the form. I can see how HTMX would not help with that.
  - tored 2mo ago
    Did you try out-of-bound swap (oob) in HTMX? With that you can update any element on page, e.g. three different form elements changed due to <select> change, request returns only these three form elements with oob selectors and keep the rest of the form intact. https://htmx.org/attributes/hx-swap-oob/ https://htmx.org/attributes/hx-swap-oob/
_HMCB_ 2mo ago
Why is this the top-most comment when the user obviously didn’t know how to use HTMX?
- james2doyle 2mo ago
  I used HTMX to serve my HTML partials. My HTML partials got too big. Not HTMXs fault. How do I fix that? Split them up? Use lazy loading? Pagination? That isn’t clear. I settled on a solution that gave me the least compromises while not abandoning the sprit of HTMX and HATEOAS. HTMX has a whole section on their site dedicated to reasons not to use HTMX: https://four.htmx.org/essays#counterpoints https://four.htmx.org/essays#counterpoints Alpine Ajax is actually promoted on their site as an alternative option but to stay within the HATEOAS universe: https://four.htmx.org/essays/alternatives#alpine-ajax https://four.htmx.org/essays/alternatives#alpine-ajax I tried building something more than a like-button or simple search. It wasn’t that easy to wrangle once it got more complicated.
selfmodruntime 2mo ago
> The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form with some large select lists as well as the response of results became noticeable laggy when there was more than a half dozen results. Welcome to the disadvantage of server side rendering. We kind of had a point when we decided on delivering a single JS package up front and only tiny changed JSON after.
deleted 2mo ago
[deleted]
HackerThemAll 2mo ago
You can bring anything to its knees when requesting too much data at once. There's always another bottleneck. Getting all data in a single request is an antipattern to me. Fetching a lot of data unless absolutely necessary with no other option is an antipattern to me. But that of course is relative to a specific purpose.
Elzair 2mo ago
For some reason this subthread reminds me of the old joke about how to get Linux tech support. https://www.reddit.com/r/ProgrammerHumor/comments/7p88zj/asking_help_in_linux_forums/ https://www.reddit.com/r/ProgrammerHumor/comments/7p88zj/ask...

inigyou 2mo ago

have a look at https://segor.de/ https://segor.de/ - it just downloads 2MB of product listing data (pre-dating JSON!) and then does all filtering client-side

benbristow 2mo ago
[dead]

brabel 2mo ago

You swapped out HTMX because you couldn’t figure out how to load a list of items gradually instead of all at once??

tclancy 2mo ago
Want to help rather than throw tomatoes?
- brabel 2mo ago
  It was a genuine question. I’ve implemented infinite scrolling in HTMX and it’s quite easy, another commenter posted an example from the HTMX docs and it’s a couple of lines of html.
  - zx8080 2mo ago
    No worse thing for ux as the infinite scroll. As it breaks the native cmd-f/ctrl-f page search and makes loading progressively slow.
    - brabel 2mo ago
      It doesn't do such thing at all, unless you think it's acceptable to load EVERYTHING in HTML, hide it, and do front-end search. Which would be completely nuts to do for things where infinite scroll is used.
      - zx8080 2mo ago
        It's a blatant lie and bullshit. A github MR can be 5Mb size and my laptop has 64Gb RAM (swappable 3x of that to SSD if really needed). There's NO need for progressive loading there. Another example is filtered goods at the local electronics store webfront. Progressive loading without ability to go directly to page 7 wastes my time if I know that what I need is there as each load of 10 items takes time. But of course this pattern increases some shitty OKR in time-spent-on-website. Hate this.
Capricorn2481 2mo ago
Wouldn't constantly loading new items into a select form be super annoying? Can HTML even keep a select input open when new items are added?

dsego 2mo ago

You can always make the server-side render partials based on a request header. https://github.com/dsego/ssr-playground/blob/main/src/server.js#L61-L74 https://github.com/dsego/ssr-playground/blob/main/src/server...

james2doyle 2mo ago
That is what I did. I was using Astro which has full support for partial HTML via the router
- dsego 2mo ago
  I think I understand now, even the partial required submitting everything to the server, which can be skipped if you can have interactivity without unnecessary requests.
  - james2doyle 2mo ago
    Exactly. The partial response was 100kb-200kb of HTML + the backend query time. Of course, depending on your filters. But a large chunk of that was just sending down the form on the left side, which I already had on page load, so that penalty was real. It was only the right side results of the experience that needed to be refetched when the form changed. But in HTMX, you are expected to just send the whole dang thing back for every change. Makes sense for a like-button, a dialog, or even a classic form submission. My refactor cut the HTML response by about 70kb and that made a big difference. The form became fully static and I had a simple Alpine data component that would just sync that state with the URL. Still used a GET on the form and still used the same partial endpoint. Just way less HTML to wait for.
    - WD-42 2mo ago
      Why are you expected to send down the whole thing? Maybe I’m missing something, but when you send the request from the form the response is just a partial of the results on the right hand side, using hx-target to specify some div instead of replacing the form. Form just stays there?

bee_rider 2mo ago

AJAX is old tech though, using stuff that worked in the year 2000 is cheating in 2026. You are supposed to make the site slow and bloated for some reason.

james2doyle 2mo ago
It isn’t literally AJAX. Just a catchy name. It is just a fetch wrapper that mimics the $get, $post, etc. API

papanoah 2mo ago

Is there a reason why you don't have an endpoint + template that renders only the result list. The form could be separate thing and issue a form submit request with all the selected filters? Seems better than rendering the whole page. You could even display a loader while the results are loading, and swap the list html element on success.

james2doyle 2mo ago
That is what I ended up doing but once I did that, I had a hell of a time getting that dynamic form working well with just the HTMX primitives. I even tried to do two different partials that would be fetched when I needed each one to rerender. The gist of what I was saying was that once I had a more complicated experience, the benefits of just fetching a fresh partial each time started to dwindle. The HTML response grew, I needed a bunch of inline handlers to patch over some state issues, as well as the complexity of the template, just started to be too much. Really it was the Alpine part that I was missing. Simple class toggles, easy way to toggle aria attributes, show/hide for elements, and reactive/computed values, were the things I needed to get the results the client wanted. If I was building a simple search input + results, I would use HTMX all day. These forum people make it work and that seems like a great use case. But it just didn’t fit with a more sophisticated form that had dynamic options plus a large results display and the burden of a slower query to just get the data.

nine_k 2mo ago

Despite the fact that HTMX is a good solution in many cases, it's not the best solution in all cases. Ditto for React, and for any technology actually. Planning and consideration are always required, if you care about the end result.

james2doyle 2mo ago
Yeah, exactly. People seem to think I was holding it wrong. Maybe! But I gave HTMX an honest try. Another team would have just done a whole React thing, no HATEOAS, boatload of JS, and a bunch more memory. I will likely use HTMX again for something when I think it makes sense. Maybe once the 4.0 beta is over though

sequoia 2mo ago

I can't really understand what you're describing. You have form on left & results on right, but you're requesting the new form state & re-rendering the form HTML on each request? Why? My naive understanding is that you could use something like hx-target to have the response to the form submissions update only the results area & the form should not need rerendered at all. Why does the form need rerendered on a per request basis? HTML/Browser already tracks the current form state.

james2doyle 2mo ago
Because the form changed based on the selections you made. Like facet search. Say you have a clothing store listing page and you filter for only "Shirts". Well, the filter that has "Material" might remove (or disable) the option for "Denim" because that is only for "Pants". So that state needs to be computed some where. My thought was, "Ok, refetch the whole thing with the updated options within the form (disable options that can’t be combined together) + the product results for those filters". But that was just a lot of HTML to ask for after each change. So decoupling it so that the form never refetched, just the results, made it a lot snappier. But you still have the form state issue where you want to update the options based on selections. So the form became a little Alpine data component and the results stayed as an HTML partial.
- sequoia 2mo ago
  Ah OK, so you had a level of dynamic behaviour in the form itself that warranted an applet/data component for the form. I can see how HTMX would not help with that.
- tored 2mo ago
  Did you try out-of-bound swap (oob) in HTMX? With that you can update any element on page, e.g. three different form elements changed due to <select> change, request returns only these three form elements with oob selectors and keep the rest of the form intact. https://htmx.org/attributes/hx-swap-oob/ https://htmx.org/attributes/hx-swap-oob/

_HMCB_ 2mo ago

Why is this the top-most comment when the user obviously didn’t know how to use HTMX?

james2doyle 2mo ago
I used HTMX to serve my HTML partials. My HTML partials got too big. Not HTMXs fault. How do I fix that? Split them up? Use lazy loading? Pagination? That isn’t clear. I settled on a solution that gave me the least compromises while not abandoning the sprit of HTMX and HATEOAS. HTMX has a whole section on their site dedicated to reasons not to use HTMX: https://four.htmx.org/essays#counterpoints https://four.htmx.org/essays#counterpoints Alpine Ajax is actually promoted on their site as an alternative option but to stay within the HATEOAS universe: https://four.htmx.org/essays/alternatives#alpine-ajax https://four.htmx.org/essays/alternatives#alpine-ajax I tried building something more than a like-button or simple search. It wasn’t that easy to wrangle once it got more complicated.

selfmodruntime 2mo ago

> The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form with some large select lists as well as the response of results became noticeable laggy when there was more than a half dozen results. Welcome to the disadvantage of server side rendering. We kind of had a point when we decided on delivering a single JS package up front and only tiny changed JSON after.

deleted 2mo ago

[deleted]

HackerThemAll 2mo ago

You can bring anything to its knees when requesting too much data at once. There's always another bottleneck. Getting all data in a single request is an antipattern to me. Fetching a lot of data unless absolutely necessary with no other option is an antipattern to me. But that of course is relative to a specific purpose.

Elzair 2mo ago

For some reason this subthread reminds me of the old joke about how to get Linux tech support. https://www.reddit.com/r/ProgrammerHumor/comments/7p88zj/asking_help_in_linux_forums/ https://www.reddit.com/r/ProgrammerHumor/comments/7p88zj/ask...