[cyanregiment]

Because I would need to see a UI paradigm prove it can handle performance before considering using it for UI.

react-three-fiber solves a lot of problems. React state is also perfectly in line with game loop architecture, r3f unifying the Three.js/React render loop is incredibly good for game dev.

But even for SaaS or whatever, I need to know that it can handle complex states of the UI - HTMX can't.

They are overselling it. It's not really a competitor to React, it's more like a competitor to Jade templating or HAML which nobody already uses anymore.

[vb-8448]

If I have to build something that is basically logic on backend, forms, tables, some static pages, some interactivity here and there(btw is what most of the sites and web apps out there are) I don't need 3d or game engine capabilities ...

And no way react is going to be faster for the above use case.

You miss the point of tools like htmx/datastar/turbo/unpoly/alpine, they are not a react competitor in the rich and complex web apps space. They fill a gap between the native browser capabilities and tools like react/vue/svelte/ecc.

[cyanregiment]

HTMX makes it hard to build even basic things, because it swaps entire HTML forcing a full repaint. That's the foundation of how it works.

Examples include user highlighting text - swap wipes that out. Or user mid scroll through a menu, the scroll is reset to the top.

It's not enough in HTMX to just break it down into smaller components, the scrolling part is native to the browser, so is text selection.

Some people forget or don't know how much an SPA library like React is doing to prepare the SPA before you get into any of the organizational framework usage. Beyond that, clever engineering went into React DOM reconciliation in particular that I rarely see challenged in other libraries.

On game dev: I think it's good for a showcase because it shows the limits of what it could do at 60+ fps in a performance intensive environment. But yeah, even a complex SaaS demo would do.

> They fill a gap between the native browser capabilities and tools like react/vue/svelte/ecc.

Have not heard that yet, since a big part of HTMX is manipulating the DOM and binding events. I'm pretty sure this is not correct

[vb-8448]

> Have not heard that yet, since a big part of HTMX is manipulating the DOM and binding events. I'm pretty sure this is not correct

Did you ever open the htmx home page? Because it's at the very top in the "motivation" section!

I'm starting to wonder whether you're trolling or you have no idea what HTMX and similar tools actually do.

[cyanregiment]

Google result for "htmx with react"

"HTMX and React represent fundamentally different web development architectures, but they can be compared or even used together in a hybrid setup."

I see tutorials on how you can mix it with React for Next.js which might make sense at the page level because it's SSR.

Definitely possible, sure. But it would be about like mixing Angular with React where two libraries are competing for the truth of what's in the DOM.

There was a time Three.js "couldn't work" with React because they each had their own separate render lifecycles - but r3f happened with enough demand (and useFrame bridged the two beautifully).

Maybe the same will be true of HTMX, maybe people are actually trying to do that now for some reason, but yeah a lot would have to change with either React or HTMX to get value out of both simultaneously for UI.

[Aeolos]

Having used both in anger, I find d* has a lot of very real advantages over react if you care about performance and application stability.

It's simple enough that you don't need training or lengthy guides about "the rules of books etc".

It's small enough that an LLM can store the entire thing in context and answer your questions.

And it doesn't npm or a build step.