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.
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
"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.
> 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.
I 100% disagree with this comment.
Lets make this clear, htmx does not swap 'entire html' - you have control to refresh whatever section of the page. That is not a full repaint.
I am beginning to wonder what tests you have done in htmx before making such a verdict.
Yes - I break my Views into "small components" - I guess it's better to say I create a lot of Partial Views. I follow a simple 'where there's one, there's many' mindset. All Partial Views are designed to return an array, even if what I need is a single record.
> Examples include user highlighting text
I've written an Application (in htmx) that has a text area for sentences. There is 'compile' function that breaks down the sentence, colouring specific words/phrases. How does it do this? htmx! It sends it back to the server-side and builds the sentence.. returning back the html with coloured texts and other meaningful attributes. It overwrites that section of the screen. It is light and fast!
The great thing is all validation and html rendering is done of the server-side. No code duplications or anything.
Now, this is perfectly fine for what I am doing. However, the text is barely no more than 30 words. If I was trying to write a text editor the we have a different type of problem. If using htmx, would likely work it out to update a portion of the editing code, perhaps per line. This would move it away from using a text area.
> Or user mid scroll through a menu, the scroll is reset to the top
I believe, with the text solution I mentioned above, I also pass it the cursor position. As we are processing the text, any changes may move the cursor - so I let the server-side handle it. This is great because the functionality written is not designed for just the web - but any 'text area' in any GUI!
From memory, with some javascript, I managed to return to the caret position once the html section was refreshed. I cannot remember 100% how I did this as I do not have access to the source code.
> On game dev: I think it's good...
I've already commented about game dev and htmx. I will paste that section here:-
Would I use htmx if writing a web-based game? probably not. I guess it would depend. I would assume I'd be writing a fair be of javascript for WebGL-based rendering and typical update logic (input, physics, health, etc)
Maybe WASM is a better choice in this domain. I don't know.
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.