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

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

#221

Post by asdfsa32 » Mon, Aug 03, 2026, 2:57 AM UTC

monooso wrote: post #216

asdfsa32 wrote: post #210

Earlier quoted context omitted.

I listed frameworks that makes majority of the market share that are based on JSX and react-like reconciliation loop. This architecture is also now dominate in the mobile apps space via React Native and Flutter as well. So I am not sure what you're talking about. The industry has largely stabilised on this architecture because it works. So I don't know who this "we" you're talking about or what you're even talking ab…

You specifically said JSX, which is a JavaScript syntax extension. You made no reference to architecture. If you want to move the goalposts to suit your argument, go right ahead; I won't be participating.

Yeah, I did say JSX but in the overall context:

> Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management, Google really really tried that with Angular 1.0, and we know it doesn't scale.

You're just arguing for sake of arguing. Goodluck.

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

#222

Post by yawaramin » Mon, Aug 03, 2026, 5:59 AM UTC

asdfsa32 wrote: post #220

yawaramin wrote: post #180

Earlier quoted context omitted.

Most webapps out there will never need the level of complexity of SPA frameworks. They will work completely fine for the foreseeable future with something like htmx. The GitHub notifications update bug is more of an eventual consistency issue than a ‘forgetting to update the UI’ issue.

Do you like programming in Blub? Because you're telling me that Static Pages are not good enough but React is too much, only Blub is the one true ideal.

One man’s React is another man’s Blub.

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

#223

Post by asdfsa32 » Tue, Aug 04, 2026, 1:47 AM UTC

yawaramin wrote: post #222

asdfsa32 wrote: post #220

Earlier quoted context omitted.

Do you like programming in Blub? Because you're telling me that Static Pages are not good enough but React is too much, only Blub is the one true ideal.

One man’s React is another man’s Blub.

Obviously you missed the entire point of the conversation if you think it is "React good". It is about a paradigm, one that is grounded in mathematical soundness, of course, that doesn't mean the implementations out there are perfect and flawless, but that is not the point.

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

#224

Post by Skinney » Tue, Aug 04, 2026, 10:18 AM UTC

shooly wrote: post #217

Skinney wrote: post #191

Earlier quoted context omitted.

React itself, or Preact for that matter, is just the baseline. You still need the application itself, which in every application I’ve worked on is quite a bit bigger than the framework itself. So you need to download the app, maybe have that app perform some fetch requests, then have the app generate html to show to the user. This is going to be slower than just retriving the resulting html directly. If you’re in a p…

> every application I’ve worked on is quite a bit bigger than the framework itself That's why most client-side routing libraries support lazy loading. You don't have to load the entire application at once, only the parts you need. > So you need to download the app, maybe have that app perform some fetch requests That's... completely unrelated to React, though? Parent comment claimed that React is slow and HTMX fast -…

> That's why most client-side routing libraries support lazy loading.

Trading off total size with more network requests.

> does HTMX make fetches magically faster or what?

With backend rendering (htmx) you'd do all of that on the initial render, which would be faster than first fetching the app, then fetching the data, as you'd typically do in a single page app.