3 ms·

I think this is a bit of reductionist interpretation of what I'm saying. Yes, it's technically correct that the attributes on a form change the type request mad

I think this is a bit of reductionist interpretation of what I'm saying. Yes, it's technically correct that the attributes on a form change the type request made. That's not really what I'm talking about, though. In the same way that I wouldn't want to manually type a lot of CSS into a style attribute, I wouldn't want to write a small program in an hx-trigger attribute. Something like hx-trigger="input changed delay:500ms, search" is getting rather complicated, imo, and it's a new DSL with new semantics to understand. And then the recommended escape hatch is... yet another new language? I dunno I just feel like there's something missing here.

alexpetros 3y ago
I somewhat agree with you but I think it's important to clarify whether you're talking about htmx or the hx-trigger syntax specifically. In the parent comment you say: > However, I think there's a pretty significant language design problem and htmx's solution is language proliferation. There is a very low "expressivity ceiling" for what can be encoded into html attributes. And then here you say: > In the same way that I wouldn't want to manually type a lot of CSS into a style attribute, I wouldn't want to write a small program in an hx-trigger attribute. Something like hx-trigger="input changed delay:500ms, search" is getting rather complicated I wouldn't write a small program in the hx-trigger syntax either (although, we not only have users who do that, but have contributed to hx-trigger optimizations because they use it so heavily). Many htmx use cases don't need this at all, some need complexity up to this point, some need far more complexity. It's really up to you to decide at what point you bring in the bigger guns—whether that's hx-trigger, alpineJS, hyperscript, or a React Island. I agree that hx-trigger is a DSL, and represents the outer limits of htmx's expressivity. My objection is to the argument that htmx's attribute design is an expressivity problem, rather than a well-chosen level of abstraction for the types of problems htmx is best suited to solve (see the sibling comment about Rule of Least Power too).

alexpetros 3y ago

I somewhat agree with you but I think it's important to clarify whether you're talking about htmx or the hx-trigger syntax specifically. In the parent comment you say: > However, I think there's a pretty significant language design problem and htmx's solution is language proliferation. There is a very low "expressivity ceiling" for what can be encoded into html attributes. And then here you say: > In the same way that I wouldn't want to manually type a lot of CSS into a style attribute, I wouldn't want to write a small program in an hx-trigger attribute. Something like hx-trigger="input changed delay:500ms, search" is getting rather complicated I wouldn't write a small program in the hx-trigger syntax either (although, we not only have users who do that, but have contributed to hx-trigger optimizations because they use it so heavily). Many htmx use cases don't need this at all, some need complexity up to this point, some need far more complexity. It's really up to you to decide at what point you bring in the bigger guns—whether that's hx-trigger, alpineJS, hyperscript, or a React Island. I agree that hx-trigger is a DSL, and represents the outer limits of htmx's expressivity. My objection is to the argument that htmx's attribute design is an expressivity problem, rather than a well-chosen level of abstraction for the types of problems htmx is best suited to solve (see the sibling comment about Rule of Least Power too).