4 ms·

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 ne

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.

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.