3 ms·
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 us
by 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 agoThat'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 agoAnd 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 agoI'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.