3 ms·

One thing I see lacking with HTMX is that, eventually, someone will want to package and distribute a third party component. You say "but it's meant for small th

One thing I see lacking with HTMX is that, eventually, someone will want to package and distribute a third party component. You say "but it's meant for small things not requiring much scripting" and I say "I don't believe you - once it's in it will grow indefinitely". This is definitely possible, but unless you are using WASM or something you would have component libraries specifically built for a backend language or framework which doesn't leave us much better off. To be fair, I have not seen this stated as a goal or concern of HTMX anywhere. But, it's a concern of mine - I'm not going to build all my components from scratch all the time and this kills HTMX for me. I guess what this would look like is an encapsulated backend module with internal templating and properties that allow controlling certain behaviours or routes. Definitely doable, not thought out at all.

BiteCode_dev 3y ago
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.
Fire-Dragon-DoL 3y ago
It's already like this for complex widgets, think of wysiwyg editors with file upload, usually it is necessary to provide a compatible backend for the file upload and management
recursivedoubts 3y ago
my position is that components for htmx are simply components for HTML: they should integrate with the DOM in the standard manner: attributes, input values and standard JavaScript events. It doesn’t make sense to talk about “htmx components”, there are only html components that should play well with anything that respects the core web platform: unpoly, Hotwire, twinspark, data star, alpine Ajax or, heaven forbid, a vanilla HTML form. I recognize this may hinder htmx adoption.
logiduck 3y ago
Yeah, thats been my experience with it also. It works great for small things and getting going, but eventually the project starts to grow and you want to embed something that would be straightforward if you used a JS framework and then the spaghetti code starts as you bolt on a JS component inside of HTMX. After the 10th time you do this the project gets pretty messy and you want to just start from scratch with a conventional framework.

BiteCode_dev 3y ago

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.

Fire-Dragon-DoL 3y ago

It's already like this for complex widgets, think of wysiwyg editors with file upload, usually it is necessary to provide a compatible backend for the file upload and management

recursivedoubts 3y ago

my position is that components for htmx are simply components for HTML: they should integrate with the DOM in the standard manner: attributes, input values and standard JavaScript events. It doesn’t make sense to talk about “htmx components”, there are only html components that should play well with anything that respects the core web platform: unpoly, Hotwire, twinspark, data star, alpine Ajax or, heaven forbid, a vanilla HTML form. I recognize this may hinder htmx adoption.

logiduck 3y ago

Yeah, thats been my experience with it also. It works great for small things and getting going, but eventually the project starts to grow and you want to embed something that would be straightforward if you used a JS framework and then the spaghetti code starts as you bolt on a JS component inside of HTMX. After the 10th time you do this the project gets pretty messy and you want to just start from scratch with a conventional framework.