4 ms·

HTMX users just use existing JS components. It's not an XOR proposition.

lucasyvas 3y ago
But you should be able to distribute bundled backend and frontend logic given its paradigm. There is no guidance on what it would take to do this, or what the interface for the components should be to enable it, or how you should build and share it. Without both, I don't see the point because then you need to potentially mix multiple frontend frameworks unless you are strictly using WebComponents. It's not XOR, but it should be possible to never leave HTMX. If you might need to go outside it anyway, then there is no point - you lose SSR if you just mount a React component anyway. I understand the argument that HTMX can be complementary, but personally I'm not looking for a complementary technology. Show me how I can use it exclusively and I'll be more interested.
- BiteCode_dev 3y ago
  No, that's not the purpose nor the scope of HTMX. This is thinking in term of other types of web framework, but it's not the design of this tool. Since it's neutral to the backend or scripting tech you chose to use, it cannot, and should not, step into that realm. It provides a more simple, basic service. You may be tempted provide a django template + view + htmx reusable component. Or a rail enpoint + htmx reusable component. But that would not be universal, it would be super specific. Maybe useful in your company, across team, but that's it.
  - lucasyvas 3y ago
    That's OK - but then I'd say I'm not interested in it based on its project scope. I have enjoyed it for small demos but I wouldn't pitch it to my company to use in the real world based on its philosophy.
    - BiteCode_dev 3y ago
      That's how engineering is supposed to work: you get to decide what to use based on your problems and the nature of the solutions. Beyond the memes, this one Montana guy is very reasonable.
    - recursivedoubts 3y ago
      And yet, and yet: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
      - lucasyvas 3y ago
        I've read this and think it makes a ton of sense. I still think it's lacking an ecosystem strategy that would propel it further. I would like be able to install an HTMX component, customize the route, and have some type of lifecycle where I can plug it into the rest of my backend. I know this might seem silly but being able to easily share what you've built has been a cornerstone of every widely successful library or framework. It may not be a core goal of HTMX, but if not I'd really like to see someone attempt it to at least judge it on its merits instead of assuming it wouldn't be a useful addition. If I can cargo install an HTMX component that covers all the rendering conditions and I just need to pipe data in and out of it, I'd very much like to try that. I can rig it up in my own codebase but it's not something one would probably publish without a suggested pattern to follow.

But you should be able to distribute bundled backend and frontend logic given its paradigm. There is no guidance on what it would take to do this, or what the interface for the components should be to enable it, or how you should build and share it. Without both, I don't see the point because then you need to potentially mix multiple frontend frameworks unless you are strictly using WebComponents. It's not XOR, but it should be possible to never leave HTMX. If you might need to go outside it anyway, then there is no point - you lose SSR if you just mount a React component anyway. I understand the argument that HTMX can be complementary, but personally I'm not looking for a complementary technology. Show me how I can use it exclusively and I'll be more interested.

BiteCode_dev 3y ago
No, that's not the purpose nor the scope of HTMX. This is thinking in term of other types of web framework, but it's not the design of this tool. Since it's neutral to the backend or scripting tech you chose to use, it cannot, and should not, step into that realm. It provides a more simple, basic service. You may be tempted provide a django template + view + htmx reusable component. Or a rail enpoint + htmx reusable component. But that would not be universal, it would be super specific. Maybe useful in your company, across team, but that's it.
- lucasyvas 3y ago
  That's OK - but then I'd say I'm not interested in it based on its project scope. I have enjoyed it for small demos but I wouldn't pitch it to my company to use in the real world based on its philosophy.
  - BiteCode_dev 3y ago
    That's how engineering is supposed to work: you get to decide what to use based on your problems and the nature of the solutions. Beyond the memes, this one Montana guy is very reasonable.
  - recursivedoubts 3y ago
    And yet, and yet: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
    - lucasyvas 3y ago
      I've read this and think it makes a ton of sense. I still think it's lacking an ecosystem strategy that would propel it further. I would like be able to install an HTMX component, customize the route, and have some type of lifecycle where I can plug it into the rest of my backend. I know this might seem silly but being able to easily share what you've built has been a cornerstone of every widely successful library or framework. It may not be a core goal of HTMX, but if not I'd really like to see someone attempt it to at least judge it on its merits instead of assuming it wouldn't be a useful addition. If I can cargo install an HTMX component that covers all the rendering conditions and I just need to pipe data in and out of it, I'd very much like to try that. I can rig it up in my own codebase but it's not something one would probably publish without a suggested pattern to follow.