3 ms·

I like the basic idea of htmx: respond to user input by making server requests that return new html for a subset of the page. However, I think there's a pretty

I like the basic idea of htmx: respond to user input by making server requests that return new html for a subset of the page. 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. The hx-trigger attribute defines a new, very limited domain specific programming language for expressing side-effects with few means of combination or abstraction. For anything slightly complicated, hyperscript seems to be the favored solution which is yet another new language. All of this caused by trying to shove logic into attribute strings.

alexpetros 3y ago
This is correct, but... logic belongs in attribute strings! Even in basic HTML, it can change what kind of HTTP request your <form> makes, or what kind of value your <input> sends, or where your <a> link goes. Without question, there's a lower expressivity ceiling to attribute-based specifications, but there is a lot that you can do within that ceiling, and you benefit in other ways by keeping your application at that "level," so to speak. [0] [0] https://unplannedobsolescence.com/blog/custom-html-has-levels/ https://unplannedobsolescence.com/blog/custom-html-has-level...
- davexunit 3y ago
  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).
nine_k 3y ago
Often you want to limit the expressive power, in order to obtain other important guarantees. E.g. much of the time you don't want a Turing-complete language, because it must be able to express a never-terminating program. HTMX is expressive enough for many smaller cases. If your case requires more richness, you can always pick React, Vue, Elm, etc, and be able to do basically anything on the client side.
- davexunit 3y ago
  Give a programmer a non-Turing complete language and they will use a Turing complete language to compile down to it. When a program is only configurable in YAML, someone will use jinja2 to generate it so they can have loops. SASS exists because CSS isn't expressive enough. Etc. etc. etc. I just really don't subscribe to purposely limiting expressive power via non-Turing completeness. I've never wanted to do this in my own software and it's only ever been a roadblock for me to route around as a user. Spent a lot of time in DevOps where this sort of thing is rampant.
  - nine_k 3y ago
    There are underpowered languages / tools, that can only solve a problem for which they are intended poorly. But not all limited tools are like that. Say, eBPF is prominently not Turing-complete, which allows to guarantee that a eBPF program terminates, and even how soon. Still eBPF is hugely useful in its area. Or, say, regular expressions are limited to regular languages; in particular, they famously [1] cannot process recursive structures, like trees. Still tools like grep / ag / rg are mightily useful. Yes, I agree that YAML is underpowered for proper k8s configuration! But it's also too powerful for its own good in other aspects [2]. I wish Google used Dhall [3] or their own purely functional config language (FCL? I already forgot the name) instead of YAML; sadly, they did not. [1]: https://stackoverflow.com/a/1732454/223424 https://stackoverflow.com/a/1732454/223424 [2]: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr... [3]: https://dhall-lang.org/ https://dhall-lang.org/
gio 3y ago
I think htmx is using the Rule of least power which "suggests choosing the least powerful [computer] language suitable for a given purpose" https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power
jsunderland323 3y ago
This has always been my take too, it reeks of a DSL. It's sort of like a no-code/low-code solution for people overwhelmed by the complexity of the FE ecosystem and/or those who don't want to learn anymore web technology but are proficient backend engineers. This is a completely understandable feeling and I have this feeling almost every day. I think DSLs that abstract markup work great for personal projects (just as a CMS works great for personal websites and marketing blogs), but for anything that starts picking up utility you will inevitably have to do something that breaks out of the DSL's abstraction. Here's my fear of using DSLs like htmx. At first the escape hatch is your friend but eventually the project stops being an htmx project and becomes a "hyperscript" (or equivalent) project. For anything that reaches maturity, you're then left with the painful task of figuring out how to port hyperscript and htmx to react/vue/svelte (the very thing you were trying to avoid in the first place). This is way harder and more painful than using one of these frameworks as a foundation for your project. What I don't get is why people that harbor this resentment to FE tech, don't just limit their feature usage. Think server components are dumb -- don't use them! Think react hooks are stupid -- write class components! In the event you actually have to do something that requires you to do something outside of your comfort-zone, you just have to push a little bit of your react/vue/svelte knowledge instead of appending more escape hatches to an increasingly bastardized DSL abstraction.

alexpetros 3y ago

This is correct, but... logic belongs in attribute strings! Even in basic HTML, it can change what kind of HTTP request your <form> makes, or what kind of value your <input> sends, or where your <a> link goes. Without question, there's a lower expressivity ceiling to attribute-based specifications, but there is a lot that you can do within that ceiling, and you benefit in other ways by keeping your application at that "level," so to speak. [0] [0] https://unplannedobsolescence.com/blog/custom-html-has-levels/ https://unplannedobsolescence.com/blog/custom-html-has-level...

davexunit 3y ago
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).

nine_k 3y ago

Often you want to limit the expressive power, in order to obtain other important guarantees. E.g. much of the time you don't want a Turing-complete language, because it must be able to express a never-terminating program. HTMX is expressive enough for many smaller cases. If your case requires more richness, you can always pick React, Vue, Elm, etc, and be able to do basically anything on the client side.

davexunit 3y ago
Give a programmer a non-Turing complete language and they will use a Turing complete language to compile down to it. When a program is only configurable in YAML, someone will use jinja2 to generate it so they can have loops. SASS exists because CSS isn't expressive enough. Etc. etc. etc. I just really don't subscribe to purposely limiting expressive power via non-Turing completeness. I've never wanted to do this in my own software and it's only ever been a roadblock for me to route around as a user. Spent a lot of time in DevOps where this sort of thing is rampant.
- nine_k 3y ago
  There are underpowered languages / tools, that can only solve a problem for which they are intended poorly. But not all limited tools are like that. Say, eBPF is prominently not Turing-complete, which allows to guarantee that a eBPF program terminates, and even how soon. Still eBPF is hugely useful in its area. Or, say, regular expressions are limited to regular languages; in particular, they famously [1] cannot process recursive structures, like trees. Still tools like grep / ag / rg are mightily useful. Yes, I agree that YAML is underpowered for proper k8s configuration! But it's also too powerful for its own good in other aspects [2]. I wish Google used Dhall [3] or their own purely functional config language (FCL? I already forgot the name) instead of YAML; sadly, they did not. [1]: https://stackoverflow.com/a/1732454/223424 https://stackoverflow.com/a/1732454/223424 [2]: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr... [3]: https://dhall-lang.org/ https://dhall-lang.org/

gio 3y ago

I think htmx is using the Rule of least power which "suggests choosing the least powerful [computer] language suitable for a given purpose" https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power

jsunderland323 3y ago

This has always been my take too, it reeks of a DSL. It's sort of like a no-code/low-code solution for people overwhelmed by the complexity of the FE ecosystem and/or those who don't want to learn anymore web technology but are proficient backend engineers. This is a completely understandable feeling and I have this feeling almost every day. I think DSLs that abstract markup work great for personal projects (just as a CMS works great for personal websites and marketing blogs), but for anything that starts picking up utility you will inevitably have to do something that breaks out of the DSL's abstraction. Here's my fear of using DSLs like htmx. At first the escape hatch is your friend but eventually the project stops being an htmx project and becomes a "hyperscript" (or equivalent) project. For anything that reaches maturity, you're then left with the painful task of figuring out how to port hyperscript and htmx to react/vue/svelte (the very thing you were trying to avoid in the first place). This is way harder and more painful than using one of these frameworks as a foundation for your project. What I don't get is why people that harbor this resentment to FE tech, don't just limit their feature usage. Think server components are dumb -- don't use them! Think react hooks are stupid -- write class components! In the event you actually have to do something that requires you to do something outside of your comfort-zone, you just have to push a little bit of your react/vue/svelte knowledge instead of appending more escape hatches to an increasingly bastardized DSL abstraction.