Earlier quoted context omitted.
Want to help rather than throw tomatoes?
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.
Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)
161–170 of 224 posts
Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)
#162I 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 w…
Why is this the top-most comment when the user obviously didn’t know how to use HTMX?
HTMX has a whole section on their site dedicated to reasons not to use HTMX: 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
I tried building something more than a like-button or simple search. It wasn’t that easy to wrangle once it got more complicated.
Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)
#163This happened 3 years ago... wondering what makes it news worthy today?
We need a follow up, how this change panned out, how much did performance improve?
The improved performance wasn't the main goal, but the HTMX version feels snappier on my purposefully mid test device (Xiaomi Redmi 8 4GB RAM).
Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)
#164Earlier quoted context omitted.
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 req…
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 opt…
Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)
#165Earlier quoted context omitted.
How does the PWA work offline with HTMX? The “hit the server for fresh markup fragments” approach seems like it has to be abandoned here, however simplifying it is for online apps.
It seems like the wrong tool for the job to me, but I was curious and thought about it a little: After initial page load, a service worker could intercept all the HTMX app's AJAX requests, but it could only work with what's already cached. Using a lot of tooling like workbox the developer could pre-cache the entire app. (Would that mean no dynamic responses?) Alternatively, implement the entire HTMX app in JS, build…
Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)
#166Earlier quoted context omitted.
You have to build a proper PWA with a fully formed manifest.json first off. Web Push (i.e: Push Notifications) are fully supported on both iOS and Android. The Only thing that doesn't work is "background" work (but preactically speaking I haven't really needed it). If you'd like to find out how I build Mobile-first apps with Go, HTML and HTMX hit me up.
Any chance you could write a hello world repo of this stack and post a link here?
Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)
#167Earlier quoted context omitted.
Unless there's a material change to the form, why not just update the changed parts? I'd also question architectural decisions if you need to send 100kb+ of html down the wire for a partial.
The cards contained a large data table outlining a bunch of attributes across many columns and rows. Not an ideal design but the client wanted those stats included in the card so they were visible right away. We could have paginated the results, but the client didn’t want that either because you are just promoting the results that happen to land on the first page. You also can’t just CTRL-F and find things that way.…
Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)
#168Earlier quoted context omitted.
Infinite scroll with htmx: https://htmx.org/examples/infinite-scroll/
It’s funny how hilariously simple that is and the parent commenter making it sound like you need a full JS framework for that instead.
Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)
#169Earlier quoted context omitted.
Based on skimming the couple sibling comments, I believe the issue you have had with htmx is precisely that you have somehow conflated it with angular. If you think they're the same, you will use them the same and have the same poor outcomes. In another comment, you mentioned State Management. If this is on your mind then you are using htmx wrong. You should not be managing any client side state with htmx. State is o…
> If you have separate state on the client that needs to be managed, you are going to have a bad time regardless of framework. Yeah, because clients never need to keep track of state like which block is expanded or which tab is selected or that the previous page was or what the user is currently typing...
Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)
#170I 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 w…
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.