7 ms·

I'm for people creating things they want to use. I also have a negative, possibly unfounded reaction to the stated purposes of htmx: >Why should only <a> and <

I'm for people creating things they want to use. I also have a negative, possibly unfounded reaction to the stated purposes of htmx: >Why should only <a> and <form> be able to make HTTP requests? >Why should only click & submit events trigger them? >Why should only GET & POST methods be available? >Why should you only be able to replace the entire screen? >By removing these arbitrary constraints, htmx completes HTML as a hypertext" I guess people do all of these things with javascript anyways but it gave me a "get off my lawn" reaction when I read these bullets.

danielvaughn 3y ago
I've already linked in another comment on this thread so I won't repeat it, but there's a book explaining why. I didn't know this prior to reading the book, but the original intent of RESTful APIs were to use hypermedia as the engine of application state (HATEOAS). Terrible acronym, but a really interesting idea. There's a lot to say about it, but the essential idea is that if you let the server control the state of the application via hypermedia requests/responses, you eliminate a lot of the complexity that is associated with client-side web apps.
- nsonha 3y ago
  [flagged]
  - yoru-sulfur 3y ago
    I think that dismissing it out of hand as useless is unproductive. From my understanding Roy Fieldings dissertation was a description and formalization of the web as it has been built, not just prescriptive advice on software architecture. To say it's not useful is to ignore how humans browse the web.
    - nsonha 3y ago
      my memory is hazy but aren't semantic web, ontology and all that HATEOAS stuff for bots instead of humans? Now that LLM is here, what use do they have?
      - hobs 3y ago
        Structured data doesn't magically go away because you have better interpretation of unstructured data that doesn't blow goats; it's still orders of magnitude easier to manage, store, and retrieve structured data.
        nsonha 3y ago
        the web is not data, this is the fundamental thing that's problematic about that way of thinking. We already have structured data, it's called database
      - yoru-sulfur 3y ago
        Funny enough I recently ran into a very relevant blog post: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h... HATEOAS is for humans I haven't really thoughy about REST in relation to all the recent ML advancements. REST (With HATEOAS) might actually be a good way to expose APIs to these agents since they now have some ability to "reason" about responses beyond a hardcoded set of handlers
- relativeadv 3y ago
  I read a good chunk of the Hypermedia book and much of the argument is an appeal to authority around the fact that "real" REST design uses HATEOAS and well because Roy Fielding said so in 2000. Yes, I get that duplicating state on the client and the server is a headache. But are people really doing that? You're just moving the state toward the client and keeping the backend much more thin. Are we going to ignore the past twenty or so years of CPU improvements? I'm not saying just yolo it and do loads of pointless expensive work on the client but 5G and modern phones should have some place in this calculus.
  - danielvaughn 3y ago
    The latter half of your comment seems to assume that the primary reason for hateoas would be performance. I'm sure many people would make that argument, and I do think it makes sense even today, but that's not really why I'm into it. I personally find consuming JSON APIs cumbersome and prone to errors. It seemed like a great idea when we first started doing it, but these days I'm keen to explore other options. I'm under no illusion that HTMX doesn't have it's own tradeoffs, but I like the return-to-tradition approach it's taking.
    - relativeadv 3y ago
      I can definitely get on board with that idea. It is indeed cumbersome dealing with some JSON api that you may or may not have written. The amount of boilerplate you must write in react just to fetch the freaking thing and do some work an display a result is rough compared to the same thing in django-htmx. But we are talking mostly about developer-experience here and while that is great, it is a compromise compared to user experience. Getting a little delay for an ajax call on much many more interactions is a thing and its there. Maybe that makes sense for many but it should be noted just like deciding to write a react PWA instead of a fully native ios app is a tradeoff for developer experience (or a dozen other reasons) instead of user experience.
      - wild_egg 3y ago
        > Getting a little delay for an ajax call on much many more interactions is a thing and its there. HTMX has a preload extension which has fully eliminated these delays in my experience. YMMV of course but so far both my UX and DX are dramatically improved over what the previous SPA offered
- badbotty 3y ago
  Are you against using something like json-ld, hal,... for embedding links? Adding arbitrary hx- attributes to html which require a javascript application to make use of comes across as un-RESTful as doing so in json to me. Not saying you have to prefer it, but some of the htmx articles imply there is a difference.
fiddlerwoaroof 3y ago
My favorite thing about HTMX is being able to do SPA-like experiences without writing anything besides my Common Lisp server code. Making hypertext just a view layer again really increases the joy of web programming for me.
- worthless-trash 3y ago
  I've written some demos in CL with htmx( https://github.com/wmealing/learn-htmx https://github.com/wmealing/learn-htmx ) and have it shipping in production. Sadly, I can't share the source for those. You got any public repos of your work ? I'm itching to compare notes.
  - ghomem 3y ago
    This is a toy but.... https://github.com/ghomem/definitive-web https://github.com/ghomem/definitive-web https://definitive.li https://definitive.li
    - deleted 3y ago
      [deleted]
- replwoacause 3y ago
  Same here. It’s been a game changer for me and enables me to build UI experiences that I wouldn’t be able to otherwise since I suck at JS.
- VWWHFSfQ 3y ago
  The best thing about HTMX is that jinja2 (well, minijinja in Rust) has finally become my view layer again. Bootstrap + HTMX + sprinkle in a tiny bit of jQuery and I have a fully-featured interactive webapp. Returning partial HTML from the server is a game-changing paradigm in web development.
_heimdall 3y ago
Its definitely a cheeky sales pitch, but I've yet to see a great argument against it. At best, HTMX isn't the right solution if you're already committed to one of the many client-side frameworks that HTMX attempts to offer am alternative to. To clarify, if you just use a bit of react that would work well with HTMX. But how many sites use a bit of react without a larger framework wrapped around it?
benatkin 3y ago
Why not just use Phoenix/Elixir? This is no more HTML or official than elixir, and I think the bikeshedding would ensue if people decided to agree upon a syntax and add it to the HTML spec. https://www.reddit.com/r/htmx/comments/160uuzd/whats_the_difference_between_htmx_liveview_and/ https://www.reddit.com/r/htmx/comments/160uuzd/whats_the_dif...
- quickthrower2 3y ago
  “Just”? It is a decent learning curve. Might as well say “why not just use React”.
  - alex_lav 3y ago
    I believe it's pretty clear that htmx (and Phoenix) exist (at least in part) because people specifically _do not_ want to use Javascript.
    - h0l0cube 3y ago
      More specifically they want to use one language for the front and back end
      - alex_lav 3y ago
        Well…yes, and that they don’t want that language to be JavaScript.
        h0l0cube 3y ago
        That's a conflation. I'm certain for at least some, the choice is more about using a single language than avoiding JS. I'm sure there are people using htmx who use a JS backend. That there are at least 5 LiveView clones for JS also are evidence that there's a desire to use JS for both front and back end for dynamic websites: https://github.com/liveviews/liveviews#javascripttypescript https://github.com/liveviews/liveviews#javascripttypescript
alex_lav 3y ago
It's amusing to me with how poor the state of javascript and FE software development is, a group of people commenting on htmx negatively. It seems to really boil down to the fact that non-JS people don't want to write JS, and JS people dislike that. Look at your average JS frontend and you'll find stuff way worse than the things you're complaining about wrt htmx. Live and let live, as they say.
a_subsystem 3y ago
I only love it because I'm paid huge amounts of $$$ to shill for it.
bb88 3y ago
> I guess people do all of these things with javascript anyways but it gave me a "get off my lawn" reaction when I read these bullets. So here's a response from the "get off my lawn" crowd. It's about hypertext. It's always been about hypertext. HTTP is literally "Hypertext Transfer Protocol". The term Hypertext was coined in 1963. Without Hypertext, Javascript is nothing.

danielvaughn 3y ago

I've already linked in another comment on this thread so I won't repeat it, but there's a book explaining why. I didn't know this prior to reading the book, but the original intent of RESTful APIs were to use hypermedia as the engine of application state (HATEOAS). Terrible acronym, but a really interesting idea. There's a lot to say about it, but the essential idea is that if you let the server control the state of the application via hypermedia requests/responses, you eliminate a lot of the complexity that is associated with client-side web apps.

nsonha 3y ago
[flagged]
- yoru-sulfur 3y ago
  I think that dismissing it out of hand as useless is unproductive. From my understanding Roy Fieldings dissertation was a description and formalization of the web as it has been built, not just prescriptive advice on software architecture. To say it's not useful is to ignore how humans browse the web.
  - nsonha 3y ago
    my memory is hazy but aren't semantic web, ontology and all that HATEOAS stuff for bots instead of humans? Now that LLM is here, what use do they have?
    - hobs 3y ago
      Structured data doesn't magically go away because you have better interpretation of unstructured data that doesn't blow goats; it's still orders of magnitude easier to manage, store, and retrieve structured data.
      - nsonha 3y ago
        the web is not data, this is the fundamental thing that's problematic about that way of thinking. We already have structured data, it's called database
    - yoru-sulfur 3y ago
      Funny enough I recently ran into a very relevant blog post: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h... HATEOAS is for humans I haven't really thoughy about REST in relation to all the recent ML advancements. REST (With HATEOAS) might actually be a good way to expose APIs to these agents since they now have some ability to "reason" about responses beyond a hardcoded set of handlers
relativeadv 3y ago
I read a good chunk of the Hypermedia book and much of the argument is an appeal to authority around the fact that "real" REST design uses HATEOAS and well because Roy Fielding said so in 2000. Yes, I get that duplicating state on the client and the server is a headache. But are people really doing that? You're just moving the state toward the client and keeping the backend much more thin. Are we going to ignore the past twenty or so years of CPU improvements? I'm not saying just yolo it and do loads of pointless expensive work on the client but 5G and modern phones should have some place in this calculus.
- danielvaughn 3y ago
  The latter half of your comment seems to assume that the primary reason for hateoas would be performance. I'm sure many people would make that argument, and I do think it makes sense even today, but that's not really why I'm into it. I personally find consuming JSON APIs cumbersome and prone to errors. It seemed like a great idea when we first started doing it, but these days I'm keen to explore other options. I'm under no illusion that HTMX doesn't have it's own tradeoffs, but I like the return-to-tradition approach it's taking.
  - relativeadv 3y ago
    I can definitely get on board with that idea. It is indeed cumbersome dealing with some JSON api that you may or may not have written. The amount of boilerplate you must write in react just to fetch the freaking thing and do some work an display a result is rough compared to the same thing in django-htmx. But we are talking mostly about developer-experience here and while that is great, it is a compromise compared to user experience. Getting a little delay for an ajax call on much many more interactions is a thing and its there. Maybe that makes sense for many but it should be noted just like deciding to write a react PWA instead of a fully native ios app is a tradeoff for developer experience (or a dozen other reasons) instead of user experience.
    - wild_egg 3y ago
      > Getting a little delay for an ajax call on much many more interactions is a thing and its there. HTMX has a preload extension which has fully eliminated these delays in my experience. YMMV of course but so far both my UX and DX are dramatically improved over what the previous SPA offered
badbotty 3y ago
Are you against using something like json-ld, hal,... for embedding links? Adding arbitrary hx- attributes to html which require a javascript application to make use of comes across as un-RESTful as doing so in json to me. Not saying you have to prefer it, but some of the htmx articles imply there is a difference.

fiddlerwoaroof 3y ago

My favorite thing about HTMX is being able to do SPA-like experiences without writing anything besides my Common Lisp server code. Making hypertext just a view layer again really increases the joy of web programming for me.

worthless-trash 3y ago
I've written some demos in CL with htmx( https://github.com/wmealing/learn-htmx https://github.com/wmealing/learn-htmx ) and have it shipping in production. Sadly, I can't share the source for those. You got any public repos of your work ? I'm itching to compare notes.
- ghomem 3y ago
  This is a toy but.... https://github.com/ghomem/definitive-web https://github.com/ghomem/definitive-web https://definitive.li https://definitive.li
  - deleted 3y ago
    [deleted]
replwoacause 3y ago
Same here. It’s been a game changer for me and enables me to build UI experiences that I wouldn’t be able to otherwise since I suck at JS.
VWWHFSfQ 3y ago
The best thing about HTMX is that jinja2 (well, minijinja in Rust) has finally become my view layer again. Bootstrap + HTMX + sprinkle in a tiny bit of jQuery and I have a fully-featured interactive webapp. Returning partial HTML from the server is a game-changing paradigm in web development.

_heimdall 3y ago

Its definitely a cheeky sales pitch, but I've yet to see a great argument against it. At best, HTMX isn't the right solution if you're already committed to one of the many client-side frameworks that HTMX attempts to offer am alternative to. To clarify, if you just use a bit of react that would work well with HTMX. But how many sites use a bit of react without a larger framework wrapped around it?

benatkin 3y ago

Why not just use Phoenix/Elixir? This is no more HTML or official than elixir, and I think the bikeshedding would ensue if people decided to agree upon a syntax and add it to the HTML spec. https://www.reddit.com/r/htmx/comments/160uuzd/whats_the_difference_between_htmx_liveview_and/ https://www.reddit.com/r/htmx/comments/160uuzd/whats_the_dif...

quickthrower2 3y ago
“Just”? It is a decent learning curve. Might as well say “why not just use React”.
- alex_lav 3y ago
  I believe it's pretty clear that htmx (and Phoenix) exist (at least in part) because people specifically _do not_ want to use Javascript.
  - h0l0cube 3y ago
    More specifically they want to use one language for the front and back end
    - alex_lav 3y ago
      Well…yes, and that they don’t want that language to be JavaScript.
      - h0l0cube 3y ago
        That's a conflation. I'm certain for at least some, the choice is more about using a single language than avoiding JS. I'm sure there are people using htmx who use a JS backend. That there are at least 5 LiveView clones for JS also are evidence that there's a desire to use JS for both front and back end for dynamic websites: https://github.com/liveviews/liveviews#javascripttypescript https://github.com/liveviews/liveviews#javascripttypescript

alex_lav 3y ago

It's amusing to me with how poor the state of javascript and FE software development is, a group of people commenting on htmx negatively. It seems to really boil down to the fact that non-JS people don't want to write JS, and JS people dislike that. Look at your average JS frontend and you'll find stuff way worse than the things you're complaining about wrt htmx. Live and let live, as they say.

a_subsystem 3y ago

I only love it because I'm paid huge amounts of $$$ to shill for it.

bb88 3y ago

> I guess people do all of these things with javascript anyways but it gave me a "get off my lawn" reaction when I read these bullets. So here's a response from the "get off my lawn" crowd. It's about hypertext. It's always been about hypertext. HTTP is literally "Hypertext Transfer Protocol". The term Hypertext was coined in 1963. Without Hypertext, Javascript is nothing.