> HTMX team should build a game with it. Load some 3D in WebGL/WebGPU, showcase high performance UI.
Why? Why you'd pick htmx (or even reactjs?!?) to build a game?
Why? Why you'd pick htmx (or even reactjs?!?) to build a game?
- Hm, maybe I should use react for this
- ok, why react?
- because the news of frontend's death has been overstated
???
- Because someone told me frontend was dead.
Every website you create, just like any form of application, is based on solving a particular problem. How you solve that problem can vary from dev to dev. Some devs may disagree you your solution just as you can disagree with theirs.
I do stand that htmx can be used to solve a good chunk of problems that otherwise would be done with React, or angular, and so on. Personally, I think htmx makes the problem easier to solve. Well, once you get over the learning curve of the htmx way.
To be able to build a website or SPA without writing much client code (JS, etc) is a win in my book. You don't need a dedicated front end team for larger sites. Also, the designer/UX team (if you have one) can focus on the server-side template system.
Regardless - frontend is not dead. htmx, afterwall, is written in Javascript. htmx doesn't stop you writing javascript code. It's just I hardly need it for business logic. If anything it might be used to compliment CSS.
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.
Go back to the grandparent comment, it doesn't ask why you'd choose a backend tech, the whole subthread is about frontend tech.
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.
They quite literally have a a large essay on their site dedicated to discussing when to and when not to use it: https://htmx.org/essays/when-to-use-hypermedia/
Also, it’s not at all sold as a ‘competitor to React’, it’s sold as a simpler option for many apps where React is overkill. If you want to make a game with React, no one will argue for using htmx instead. The game will probably have a lot of perf issues though.
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.
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.
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
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.
"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.
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.