3 ms·

This again? From the first page of the documentation: With that in mind, consider the following bit of HTML: <button hx-post="/clicked" hx-trigg

by hnbad 4y ago

This again? From the first page of the documentation: With that in mind, consider the following bit of HTML: <button hx-post="/clicked" hx-trigger="click" hx-target="#parent-div" hx-swap="outerHTML" > Click Me! </button> We've been through this back in the Angular days (and even before that: remember Knockout?). Implementing your template language as DOM attributes does not make it HTML. Not to mention the examples using "hyperscript", aka a "human readable" DSL for DOM manipulation and event handling also stuck in HTML attributes. If you are a Python team, sure, avoiding JS is a good idea and tools like htmx which let you pretend you're not working in multiple languages while having to memorize a massive API implemented in DSLs bolted onto DOM elements are fine. I've worked with these kinds of libraries in the past and once you can get over the knowledge gap, they can be amazing 80% solutions and solve most of your problems. If you are either a "full-stack" JS (i.e. server + client written in JS) team or have more than one person specifically working on the frontend, this can just as likely be a massive footgun because you're trading a widely used, well-understood tool with a massive community for a somewhat niche one with a much smaller (but hopefully more dedicated and helpful) community. Sorry if my assessment of htmx comes across as sarcastic but TINSTAAFL and my criticism would equally apply if the talk was about moving from Angular or Vue. If having to write JS is a drain on your team's resources and you can't change that, yes, try moving away from JS even if it means going down a less travelled path. EDIT: To be clear: one of the early selling points of React was "it's just JavaScript", referring to how most comparable tools would require you to learn their DSLs to do basic things like a loop. React allowing you to actually use a JavaScript `forEach` or build an array in your render function instead of having a `data-react-foreach` attribute or something like that on an element was a breath of fresh air as tools like AngularJS or Knockout required you to use those and were extremely inflexible because of it (e.g. if they wanted to support filtering they'd have to bake it into the DSL whereas in React you could just do an `if` or `.filter`).

recursivedoubts 4y ago
Htmx is not simply angular-style directives with client-side templates again. it is, rather, an extension of HTML as hypermedia. That's the big difference between htmx and most other front end libraries. There are a number of essays here on this difference and the ramifications of it here: https://htmx.org/essays https://htmx.org/essays
- hnbad 4y ago
  Frankly, that page in itself is the reason my comment's tone is so hostile. There are fewer "essays" on that page than "memes" which just seem to exist to ridicule frontend frameworks or smear JS in general (which is ironic given that JS itself is a "twenty years old technology", which at least one of the memes frames as superior). I put "essays" in scare quotes as the first "essay" is literally the OP article, which is primarily a video of a conference talk. The rest of the collection mostly makes philosophical arguments that wax poetical about web architecture and mostly don't reference htmx by name so I can't be bothered to dig through all of them to figure out what you're trying to tell me. "An extension of HTML as hypermedia" is not a description of what it does, it's a grandiose sales pitch. I'm familiar with the original REST paper and a lot of the philosophizing around HATEOAS and hypermedia. It's not an "extension of HTML", it's a browser runtime implemented as a JavaScript library (assuming they didn't use WASM) that executes a declarative DSL in the form of non-standard HTML attributes (like Knockout, AngularJS 1, etc) and performs XHR requests to substitute fragments (like PJAX). I'm genuinely trying to understand what makes this novel or interesting but it's hard to tell between all the obnoxious dismissiveness towards frontend frameworks (and JS) and the grandiose use of academic buzzwords. EDIT: Thank you for pointing to that page though because at least it demonstrates that HTMX is the successor to Intercooler.js, a JS framework, which has a much less grandiose description of itself that doesn't need to appeal to philosophical blog posts or shitting on JavaScript to make its point: https://intercoolerjs.org/docs.html#philosophy https://intercoolerjs.org/docs.html#philosophy In fact, this Intercooler essay explicitly names PJAX as one of the examples of the tradition it tries to build on (while trying to stay true to the principles of HATEOAS and REST).
  - recursivedoubts 4y ago
    it's always a tough balance: the reality is that htmx is hostile (or at least passive agressive :) towards JavaScript, as it is being used today. in general, I try to keep things positive and emphasize hypermedia over htmx, since it's the conceptual idea that I think is more important than htmx's implementation of it (libraries like unpoly or hotwire are also great options.) I do think htmx is more of an "extension of HTML" than those two, in that it is lower level and requires more work (or, if you prefer, has less magic) than them. the memes are what they are: it's the internet and i've gotten plenty of shit over the last decade from SPA partisans, so, at times, they are going to be a little punchy. I try not to take things personally and laugh about it all: the situation is hopeless, but not serious. the philosophical turn after I created htmx (really, intercooler 2.0) reflects that I have, over the last decade, developed a better understanding of hypermedia/REST/HATEOAS and why intercooler.js/htmx is different than SPA-talking-to-JSON-APIs. The essays certainly aren't for everyone, but I enjoy writing them and giving an alternative (and, I would argue, originalist) view of how web development can be done. tone is always hard on the internet and, broadly, I like Churchill's take: "I like a man who grins when he fights."
samwillis 4y ago
The other reply (I think by the creator of HTMX) is right, HTMX is not a DSL for DOM template manipulation, but I want to address your main point about DSLs for DOM templating. I completely see the appeal of a "it's just JS" approach that JSX and React take. But there is a massive advantage that a DSL has, the compiler can statically analyse the template and compile it in such a way that it has an understanding of what will change, what won't. This allows the compiler to make massive optimisations that JSX templates cannot do (easily). To achieve, in general, the same level of optimisation with JSX you have to code them in yourself. Whether you go for an Angular/Vue style attribute based DSL or a Handlebars-esq DSL such as with Svelt, I don't really mind, they both have advantages and disadvantages. But what they allow you to do over JSX is enormously misunderstood by the majority of React devs. There is a good overview of this in the Vue docs here: https://vuejs.org/guide/extras/rendering-mechanism.html#compiler-informed-virtual-dom https://vuejs.org/guide/extras/rendering-mechanism.html#comp...
- hnbad 4y ago
  I know, this isn't a novel concept. There was a good talk about the spectrum of abstractions and the tradeoffs of template languages vs React's approach at React Europe a couple of years ago (in fact, he goes into that this means there are some optimizations that are simply unavailable to React): https://www.youtube.com/watch?v=mVVNJKv9esE https://www.youtube.com/watch?v=mVVNJKv9esE The question isn't whether DSLs or "just JS" are more powerful, the question is which tradeoffs they represent and which tradeoffs you prefer. It seems that HTMX is primarily based in the Python ecosystem and as a former Pythonista I see the advantage of having a DSL over having to write JS, especially that the former is much narrower, which is what you want in this situation.
germandiago 4y ago
You are right about changingsupport for niche but... if the tool is easier to understand probably it is also less massive and easier to interact/find workarounds when needed than if you work on top of several layers + huge dependencies. At least that is my experience and why, in the face of choice and when it makes sense, I would choose htmx over React. It is easy to understand and a thin layer you can figure out even what it is doing under the hood. I cannot say the same about React, which is much more complicated. Sure it has good use cases. But it is more difficult to understand and potentially drags a lot of deps inside. I see every dependency on an app as introducing some risk: the more of them, the worse. They can break, they can go unmaintained, you can have a trnsitive dep that is compatible with one package but incompatible with another (this happened a lot to me with node) and that propagates recursively. It can be a hell to the point that making things work can get difficult. So at the end, if you can do something with a couple of deps and some htmx/standard web stuff and a bit of hyperscript or similar here and there, chances that things will keep working for the years coming are higher. Also, if something gets outdated there is a tiny layer to replace you can do it more easily.
- hnbad 4y ago
  Yes, it's a tradeoff. Picking up a DSL is probably faster and easier than learning an entire new language. But knowledge about that DSL is also not as readily transferrable and it's much harder to hire for someone already familiar with a DSL than one of the most widely used languages. Of course in turn you probably want a much higher level of expertise in that language than would be necessary in a DSL you can learn (and, to some degree, master) in a fraction of the time.

by hnbad 4y ago

recursivedoubts 4y ago

Htmx is not simply angular-style directives with client-side templates again. it is, rather, an extension of HTML as hypermedia. That's the big difference between htmx and most other front end libraries. There are a number of essays here on this difference and the ramifications of it here: https://htmx.org/essays https://htmx.org/essays

hnbad 4y ago
Frankly, that page in itself is the reason my comment's tone is so hostile. There are fewer "essays" on that page than "memes" which just seem to exist to ridicule frontend frameworks or smear JS in general (which is ironic given that JS itself is a "twenty years old technology", which at least one of the memes frames as superior). I put "essays" in scare quotes as the first "essay" is literally the OP article, which is primarily a video of a conference talk. The rest of the collection mostly makes philosophical arguments that wax poetical about web architecture and mostly don't reference htmx by name so I can't be bothered to dig through all of them to figure out what you're trying to tell me. "An extension of HTML as hypermedia" is not a description of what it does, it's a grandiose sales pitch. I'm familiar with the original REST paper and a lot of the philosophizing around HATEOAS and hypermedia. It's not an "extension of HTML", it's a browser runtime implemented as a JavaScript library (assuming they didn't use WASM) that executes a declarative DSL in the form of non-standard HTML attributes (like Knockout, AngularJS 1, etc) and performs XHR requests to substitute fragments (like PJAX). I'm genuinely trying to understand what makes this novel or interesting but it's hard to tell between all the obnoxious dismissiveness towards frontend frameworks (and JS) and the grandiose use of academic buzzwords. EDIT: Thank you for pointing to that page though because at least it demonstrates that HTMX is the successor to Intercooler.js, a JS framework, which has a much less grandiose description of itself that doesn't need to appeal to philosophical blog posts or shitting on JavaScript to make its point: https://intercoolerjs.org/docs.html#philosophy https://intercoolerjs.org/docs.html#philosophy In fact, this Intercooler essay explicitly names PJAX as one of the examples of the tradition it tries to build on (while trying to stay true to the principles of HATEOAS and REST).
- recursivedoubts 4y ago
  it's always a tough balance: the reality is that htmx is hostile (or at least passive agressive :) towards JavaScript, as it is being used today. in general, I try to keep things positive and emphasize hypermedia over htmx, since it's the conceptual idea that I think is more important than htmx's implementation of it (libraries like unpoly or hotwire are also great options.) I do think htmx is more of an "extension of HTML" than those two, in that it is lower level and requires more work (or, if you prefer, has less magic) than them. the memes are what they are: it's the internet and i've gotten plenty of shit over the last decade from SPA partisans, so, at times, they are going to be a little punchy. I try not to take things personally and laugh about it all: the situation is hopeless, but not serious. the philosophical turn after I created htmx (really, intercooler 2.0) reflects that I have, over the last decade, developed a better understanding of hypermedia/REST/HATEOAS and why intercooler.js/htmx is different than SPA-talking-to-JSON-APIs. The essays certainly aren't for everyone, but I enjoy writing them and giving an alternative (and, I would argue, originalist) view of how web development can be done. tone is always hard on the internet and, broadly, I like Churchill's take: "I like a man who grins when he fights."

samwillis 4y ago

The other reply (I think by the creator of HTMX) is right, HTMX is not a DSL for DOM template manipulation, but I want to address your main point about DSLs for DOM templating. I completely see the appeal of a "it's just JS" approach that JSX and React take. But there is a massive advantage that a DSL has, the compiler can statically analyse the template and compile it in such a way that it has an understanding of what will change, what won't. This allows the compiler to make massive optimisations that JSX templates cannot do (easily). To achieve, in general, the same level of optimisation with JSX you have to code them in yourself. Whether you go for an Angular/Vue style attribute based DSL or a Handlebars-esq DSL such as with Svelt, I don't really mind, they both have advantages and disadvantages. But what they allow you to do over JSX is enormously misunderstood by the majority of React devs. There is a good overview of this in the Vue docs here: https://vuejs.org/guide/extras/rendering-mechanism.html#compiler-informed-virtual-dom https://vuejs.org/guide/extras/rendering-mechanism.html#comp...

hnbad 4y ago
I know, this isn't a novel concept. There was a good talk about the spectrum of abstractions and the tradeoffs of template languages vs React's approach at React Europe a couple of years ago (in fact, he goes into that this means there are some optimizations that are simply unavailable to React): https://www.youtube.com/watch?v=mVVNJKv9esE https://www.youtube.com/watch?v=mVVNJKv9esE The question isn't whether DSLs or "just JS" are more powerful, the question is which tradeoffs they represent and which tradeoffs you prefer. It seems that HTMX is primarily based in the Python ecosystem and as a former Pythonista I see the advantage of having a DSL over having to write JS, especially that the former is much narrower, which is what you want in this situation.

germandiago 4y ago

You are right about changingsupport for niche but... if the tool is easier to understand probably it is also less massive and easier to interact/find workarounds when needed than if you work on top of several layers + huge dependencies. At least that is my experience and why, in the face of choice and when it makes sense, I would choose htmx over React. It is easy to understand and a thin layer you can figure out even what it is doing under the hood. I cannot say the same about React, which is much more complicated. Sure it has good use cases. But it is more difficult to understand and potentially drags a lot of deps inside. I see every dependency on an app as introducing some risk: the more of them, the worse. They can break, they can go unmaintained, you can have a trnsitive dep that is compatible with one package but incompatible with another (this happened a lot to me with node) and that propagates recursively. It can be a hell to the point that making things work can get difficult. So at the end, if you can do something with a couple of deps and some htmx/standard web stuff and a bit of hyperscript or similar here and there, chances that things will keep working for the years coming are higher. Also, if something gets outdated there is a tiny layer to replace you can do it more easily.

hnbad 4y ago
Yes, it's a tradeoff. Picking up a DSL is probably faster and easier than learning an entire new language. But knowledge about that DSL is also not as readily transferrable and it's much harder to hire for someone already familiar with a DSL than one of the most widely used languages. Of course in turn you probably want a much higher level of expertise in that language than would be necessary in a DSL you can learn (and, to some degree, master) in a fraction of the time.