Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

misago-project.org

Post reply on HN
Print view View original

121–130 of 224 posts

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

#121

Post by james2doyle »

brabel wrote: post #96
james2doyle wrote: post #91

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…

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

If I wanted to do that I would have added pagination. But that UX also sucks in a different way.

I think dynamically fetching results (ala infinite scroll) would have been more complicated to build. I would have had to add an intersection detection (HTMX 4 has that) to trigger the form/request again, but with an ever increasing chunk offset slice. I also need a way to track that state as well. Considering I had one big HTML response, I don’t think I could have done that efficiently without splitting it anyway. Even if I could "pluck" the results I needed from the HTML response, the penalty of waiting for the response was the factor.

If you have any links to some demos where there is something like that, I would appreciate it.

All that being said, the count of items actually isn't the most relevant part. The most relevant part is the amount of HTML per single result. If you have a sophisticated card component (a title, a description, images, a table of information inside of it or complicated layout) just loading six cards could end up being hundreds of HTML elements.

So even if you lazy loaded elements in chunks, those chunks are still gonna take a while to fetch given the size of the HTML. You also break CTRL-F-ing since those results don’t exist in the DOM until you trigger their fetching code. Same problem as classic pagination.

I would have to completely refactor my entire experience regardless because if I want to lazily load the cards/results gradually, I would have to split up the layout to make it more efficient.

So my approach to shrink the HTML response was to break it up the "live" section to just the right half.

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

#122

Post by olvy0 »

Pxtl wrote: post #101
atoav wrote: post #94

Earlier quoted context omitted.

Well I also do not really know the legitimate use case for infinite scroll (other than trying to push gambling/slot-machine tricks onto your userbase). I get lazy-loading for pages that contain a ton of media of which the user will likely only see a fraction. But some people seem to think infinite scroll is a good idea with text based content as well..

I'm specifically cranky about MS Azure Devops and how much lazy-loading and unloading of text it does. It's basically impossible to ctrl-F.

Yes! I suffer through this daily. It's atrocious.

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

#124

Post by papanoah »

james2doyle wrote: post #91

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…

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.

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

#125

Post by throwaway7783 »

robertlagrant wrote: post #63
epolanski wrote: post #56

Earlier quoted context omitted.

> A Single-Page Application (SPA) is a web application or website that loads a single HTML page and dynamically updates its content as users interact with it, rather than loading entire new pages from the server. That's the definition, I didn't made it up. And those libraries solve that. Your other definition, can be fully implemented server side, Elixir's Phoenix does that. But it's not the only one.

> That's the definition, I didn't made it up. Your prior claim was that they only solve one problem, not about a definition. They solve several problems: - less data can move over the wire compared to sending a full page every time (this is in your definition, and is definitely not always true, as sometimes REST APIs can return far more data than what's needed to render the screen) - the same REST/data API can serve…

That second point is almost never true " the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers"

In a reasonably complex application, each interface ends up needing its own shape of optimized APIs. Otherwise the clients become very complex munging/reshaping data or making too many API calls, throwing away a lot of data etc.

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

#126

Post by james2doyle »

dsego wrote: post #118
james2doyle wrote: post #115

Earlier quoted context omitted.

That is what I did. I was using Astro which has full support for partial HTML via the router

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.

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.

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

#127

Post by wredcoll »

wild_egg wrote: post #74
asdfsa32 wrote: post #22

Earlier quoted context omitted.

It is different in that some of what happened on the frontend now happens in the backend, but overall, it is the exact same approach, so as I said in a sibling comment, it, it is just a second attempt at angular 1.0 with even more naive assumptions about web.

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)

#128

Post by Pxtl »

egeozcan wrote: post #81
toddmorey wrote: post #73

Earlier quoted context omitted.

Nope, HTMX could power endless scroll features if you want them

Yes but then you're doing HTMX not HTML and at that point why not use something that's more flexible. I'm saying this as a person who still maintains a small application done with Intercooler.js and is perfectly happy with it. If you want basic interactivity, HTMX is fine. If you want something more (like sortable) I'd reach for lit instead of adding the Sortable.js dependency, something the HTMX docs suggest ( https…

> There is no golden rule to all of this but finding out what makes sense is a fun exercise.

"Fun" as in you're years into a project before you fully accept that you made the bad call.

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

#129

Post by wredcoll »

asdfsa32 wrote: post #40
monooso wrote: post #29

Earlier quoted context omitted.

> Hypermedia is what to web apps what XML is to programming languages. I have no idea what this means. The World Wide Web itself is quite literally hypermedia. The fact that a lot of front-end frameworks appear hell bent on ignoring this fact doesn't make it any less true. > Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management..…

> You may have stabilised on JSX, "we" have not. Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%. So I am not sure what "we" you are talking about.

I miss vue2.0 =[.

JSX just feels weird.

Post reply on HN