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

Post by robertoandred » Mon, Jul 27, 2026, 7:20 PM UTC

xutopia wrote: post #39

asdfsa32 wrote: post #34

Earlier quoted context omitted.

This just shows that despite the 1.6M/m budget, you did not have people who could do react correctly. React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015. But while first render is of course important, now everything else is more expensive with htmx because you have to generate HTML on the server, on top of your usual fetch pipeline. Yes…

Yes but why bother with React, Hydrating pages at all if you can do something simpler? What advantages does React provide here? HTMX tools are simpler while providing straightforward thinking around html fragment caching, whole page caching. React just gives a runaround way of doing everything. I'll remind you React was built so that people could continue watching a streamed video while they navigated on a page. Most…

Post by WhatIsDukkha » Mon, Jul 27, 2026, 7:57 PM UTC

james2doyle wrote: post #126

dsego wrote: post #118

Earlier quoted context omitted.

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…

Post by ninjis » Mon, Jul 27, 2026, 8:21 PM UTC

james2doyle wrote: post #126

dsego wrote: post #118

Earlier quoted context omitted.

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…

Post by james2doyle » Mon, Jul 27, 2026, 8:39 PM UTC

bee_rider wrote: post #120

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…

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.

Post by sequoia » Mon, Jul 27, 2026, 8:51 PM UTC

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…