4 ms·

I just had to do a site which involved a fair amount of interactivity. A sidebar with different types of filters, a search bar at the top, and a complex boolean

I just had to do a site which involved a fair amount of interactivity. A sidebar with different types of filters, a search bar at the top, and a complex boolean filter builder inside a modal (think like infinitely-nestable AND/OR filters, where each filter involved 5 dropdowns interacting with each other). Then some area to collect the results and do some operations on them. I was feeling brave and decided to skip Vue which we otherwise use for complex UIs and do the whole page with HTMX and nothing else. And it worked. It took me longer, thats for sure, but also because I had to get a feeling for how to approach many things I would have just routinely plumbed together with Vue. And the feeling at the end was really satisfying, a fast-loading, complex interactive page, powered by ~10kb of Javascript, with all filtering logic, validation etc. completely server-side (we use ASP.net). And I have confidence it will work exactly as it is years from now. With our Javascript tooling, I expect things to break by that time. That said, I certainly pushed the library in parts, and the vote is still out on how easy it will be to understand the flow of interaction if some time has passed.

yuretz 4y ago
Just curious, if it's pure htmx, doesn't this mean that most of UI interactive actions do a roundtrip to the server to update the app state? Or have you used hyperscript for some parts?
- graboid 4y ago
  Yes, no hyperscript, and yes, all interactive actions do a roundtrip. I tried not to get too detailed with the updates, so e.g. when you are in the filter builder dialog, and change the value of a select (and now the other selects have to change their data accordingly), the whole dialog is fetched again from server, instead of just the other selects. I felt that, while more selectively updating the UI would be more performant (htmx has to switch out less elements and the request payload is smaller), I don't want to cluster up my server with lots of small endpoints that return bits of HTML. All in all it was like 10 new endpoints returning HTML for that site, which was okay in my book. Could probably have been less if I had been more clever. What I learned was to really pay more attention to make my HTML "leaner" than normal, because I noticed that if I don't pay attention to that, payloads can get big quite faster than when using JSON.

yuretz 4y ago

Just curious, if it's pure htmx, doesn't this mean that most of UI interactive actions do a roundtrip to the server to update the app state? Or have you used hyperscript for some parts?

graboid 4y ago
Yes, no hyperscript, and yes, all interactive actions do a roundtrip. I tried not to get too detailed with the updates, so e.g. when you are in the filter builder dialog, and change the value of a select (and now the other selects have to change their data accordingly), the whole dialog is fetched again from server, instead of just the other selects. I felt that, while more selectively updating the UI would be more performant (htmx has to switch out less elements and the request payload is smaller), I don't want to cluster up my server with lots of small endpoints that return bits of HTML. All in all it was like 10 new endpoints returning HTML for that site, which was okay in my book. Could probably have been less if I had been more clever. What I learned was to really pay more attention to make my HTML "leaner" than normal, because I noticed that if I don't pay attention to that, payloads can get big quite faster than when using JSON.