Live data from Hacker News

Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

misago-project.org

161–170 of 224 posts

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#161
post #135

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.

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.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#162
post #157

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 w…

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

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

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)

#163
post #50

This 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?

I'll write a follow in a few months, once the thing is actually out. :)

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)

#164

Earlier 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…

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.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#165

Earlier 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…

I would recommend you have a look at Swag: https://swag.mills.io

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#166
post #140

Earlier 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?

Yes! Check out https://swag.mills.io and the examples in the repo.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#167

Earlier 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.…

If the server is using gzip, it feels like the difference in sending back json vs the larger (but compressible) html wouldn't be that much?

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#168
post #98

Earlier 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.

Infinite scroll is not a good tool for his use-case. Users will filter and then try to Cmd-F. They will get annoyed if you can’t search. It’s just bad UX. You can use infinite scroll for things like Twitter feed. Product search is just a different kind of UI.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#169

Earlier 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...

Every one of those are things that the browser manages for you if you are using semantic markup and embracing web standards.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#170

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 w…

> 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.

Post reply on HN