4 ms·

> 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 g

by vb-8448 2mo ago

> 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?

cyanregiment 2mo ago
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 2mo ago
  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.
  - Aeolos 2mo ago
    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.
  - cyanregiment 2mo ago
    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 2mo ago
      > 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 2mo ago
        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.
- yawaramin 2mo ago
  > They are overselling it. 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/ 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.
ironmagma 2mo ago
Probably because the news of frontend's death has been overstated.
- AlexeyBelov 2mo ago
  How does this answer the question? I cannot imagine an internal monologue going like this: - Hm, maybe I should use react for this - ok, why react? - because the news of frontend's death has been overstated ???
  - ironmagma 2mo ago
    - Why would you pick $backend technology? - Because someone told me frontend was dead.
    - AlexeyBelov 2mo ago
      But that's a different question and a different situation. Logically this is unsound. Go back to the grandparent comment, it doesn't ask why you'd choose a backend tech, the whole subthread is about frontend tech.
      - ironmagma 2mo ago
        No it's not. HTMX is a backend tech; it hinges on moving your presentation logic from the frontend into the backend, hence the whole hype about it supposedly obviating React.
    - masfoobar 2mo ago
      I am one of those 'htmx lovers' but I do not comment that is the be all to end all. 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.

by vb-8448 2mo ago

> 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?

cyanregiment 2mo ago

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 2mo ago
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.
- Aeolos 2mo ago
  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.
- cyanregiment 2mo ago
  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 2mo ago
    > 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 2mo ago
      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.
yawaramin 2mo ago
> They are overselling it. 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/ 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.

ironmagma 2mo ago

Probably because the news of frontend's death has been overstated.

AlexeyBelov 2mo ago
How does this answer the question? I cannot imagine an internal monologue going like this: - Hm, maybe I should use react for this - ok, why react? - because the news of frontend's death has been overstated ???
- ironmagma 2mo ago
  - Why would you pick $backend technology? - Because someone told me frontend was dead.
  - AlexeyBelov 2mo ago
    But that's a different question and a different situation. Logically this is unsound. Go back to the grandparent comment, it doesn't ask why you'd choose a backend tech, the whole subthread is about frontend tech.
    - ironmagma 2mo ago
      No it's not. HTMX is a backend tech; it hinges on moving your presentation logic from the frontend into the backend, hence the whole hype about it supposedly obviating React.
  - masfoobar 2mo ago
    I am one of those 'htmx lovers' but I do not comment that is the be all to end all. 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.