3 ms·

I'm not a fan of Javascript but my simple projects often need some interactivity that just HTML and CSS alone can't provide. Things like, "when the user clicks

I'm not a fan of Javascript but my simple projects often need some interactivity that just HTML and CSS alone can't provide. Things like, "when the user clicks thing thing, update this other thing." I thought HTMX was going to be that silver bullet that let me get away with never writing JavaScript again, but after using it in a few places, I'm a bit more selective in which projects I adopt it for: If you're doing anything fancy before or after a request, you either have to use Javascript anyway, or pull in hyperscript as another dependency and then you also have to learn hyperscript. (Some of the demos on the HTMX site require hyperscript.) Browser-native prompt dialogs send the contents of the prompt as a custom request header instead of POST data, which means you have to modify your backend routes, making HTMX much less plug-and-play. If there's a good reason for this design decision, it's not mentioned in the docs or examples. If you already know how to use querySelector(), fetch(), and innerHTML in Javascript, HTMX isn't going to offer you much except cleaner-looking code at the cost of adding a dependency to the project.

tomatowurst 5y ago
I am trying to understand better your pain points here. What other fancy cases are you referring to when you say before or after a request? Are you talking about dom events? Do you see any other scenarios where this stack setup struggles? If you were to design this how would you do it? Since I do think it is helpful in some cases like creating forms and basic navigation.
pythonaut_16 5y ago
I'm not super familiar with HTMX but lots of people in the Elixir/Phoenix/Liveview world are using Alpine JS for these types of problems. Liveview(HTMX analog) for anything with data and state that needs to go to and from the server; Alpine JS for client side interactions with ephemeral state like opening a modal.
- adfm 5y ago
  HTMX + Alpine JS seems to be prevalent.
  - reducesuffering 5y ago
    It's hilarious to me that HTMX is JS code and Alpine.js is HTML.
    - abledon 5y ago
      its js too? https://alpinejs.dev/essentials/installation#as-a-module https://alpinejs.dev/essentials/installation#as-a-module
      - reducesuffering 5y ago
        I was going by Github language stats indicating 90% HTML / 10% JS https://github.com/alpinejs/alpine https://github.com/alpinejs/alpine
recursivedoubts 5y ago
there is no silver bullet: htmx and hypermedia are a tool, and give you a pretty low-complexity solution to many problems, but eventually you will run into something that needs a more elaborate front end solution and using Alpine, vue or whatever makes sense. Hopefully by staying close to HTML's semantics and design philosophy, using htmx doesn't introduce a lot of conceptual load on top of what is already there, and saves you complexity where the more elaborate client-side stuff isn't needed.
clairity 5y ago
yes, and jquery is still useful in cases like this, despite the disdain most modern front-end devs have for it. the added weight is also not a big concern for any site not meant to serve millions of requests a day. it just has all of the core convenience methods you'd want, and a sane dev UX (unlike plain js). i'd add that stimulus is another great alternative for sprinkles of front-end interactivity without going all-in on js tooling and a js framework. it pairs nicely with rails 7's new turbo feature to provide a full server-side rendering experience, similar to htmx.
kitd 5y ago
HTMX has quite a few before/after events that you can respond to: https://htmx.org/reference/#events https://htmx.org/reference/#events
bredren 5y ago
I suspect HTMX is the salve for backend developers (particularly Python webdev) doing anything possible to avoid dealing with modern frontend and the toolchains that come with it. I’m not talking about frameworks, I’m talking about vanilla es6+ and occasionally leveraging npm the way they do Python package dependencies. I don’t blame folks for this but solid devops exists now. A lot of the pains around including modern js in a template driven web project have been worked out. The benefits including the cross browser compatibility, tree shaking and module importing and are there for the taking. Form manipulation, Ajax behaviors—-using JS to liven up your app can be learned and implemented.
- Doxin 5y ago
  Full stack dev here. I know plenty of frontend JS. I've written a chat application for my job that's currently in use by ~thousands of people among other things. This preface just to note that I'm not bad at JS or scared by it. I hate having to set up a "modern" js toolchain when starting a new project. No matter what tools you choose it's always a huge hassle, and it never manages to integrate seamlessly with the backend. What I like about HTMx and alpine.js is that first of all the set up is trivial. I just stick the js files in my static folder and stick a script tag in the header. Secondly they leverage exactly what the backend is good at: producing HTML. Getting the backend and frontend talking is trivial instead of a huge REST-y kludge. With modern JS I need to write database models, REST views, REST serializers, components, routing logic, etc. with HTMx and alpine I still need to write database models, views and templates but I get to fully skip the whole translation to and from REST (or whichever other API model you prefer). And in the end it's no less performant. So yeah for hobby projects I definitely avoid modern JS, but it's not for no reason. The developer experience is just awful IMO.

tomatowurst 5y ago

I am trying to understand better your pain points here. What other fancy cases are you referring to when you say before or after a request? Are you talking about dom events? Do you see any other scenarios where this stack setup struggles? If you were to design this how would you do it? Since I do think it is helpful in some cases like creating forms and basic navigation.

pythonaut_16 5y ago

I'm not super familiar with HTMX but lots of people in the Elixir/Phoenix/Liveview world are using Alpine JS for these types of problems. Liveview(HTMX analog) for anything with data and state that needs to go to and from the server; Alpine JS for client side interactions with ephemeral state like opening a modal.

adfm 5y ago
HTMX + Alpine JS seems to be prevalent.
- reducesuffering 5y ago
  It's hilarious to me that HTMX is JS code and Alpine.js is HTML.
  - abledon 5y ago
    its js too? https://alpinejs.dev/essentials/installation#as-a-module https://alpinejs.dev/essentials/installation#as-a-module
    - reducesuffering 5y ago
      I was going by Github language stats indicating 90% HTML / 10% JS https://github.com/alpinejs/alpine https://github.com/alpinejs/alpine

recursivedoubts 5y ago

there is no silver bullet: htmx and hypermedia are a tool, and give you a pretty low-complexity solution to many problems, but eventually you will run into something that needs a more elaborate front end solution and using Alpine, vue or whatever makes sense. Hopefully by staying close to HTML's semantics and design philosophy, using htmx doesn't introduce a lot of conceptual load on top of what is already there, and saves you complexity where the more elaborate client-side stuff isn't needed.

clairity 5y ago

yes, and jquery is still useful in cases like this, despite the disdain most modern front-end devs have for it. the added weight is also not a big concern for any site not meant to serve millions of requests a day. it just has all of the core convenience methods you'd want, and a sane dev UX (unlike plain js). i'd add that stimulus is another great alternative for sprinkles of front-end interactivity without going all-in on js tooling and a js framework. it pairs nicely with rails 7's new turbo feature to provide a full server-side rendering experience, similar to htmx.

kitd 5y ago

HTMX has quite a few before/after events that you can respond to: https://htmx.org/reference/#events https://htmx.org/reference/#events

bredren 5y ago

I suspect HTMX is the salve for backend developers (particularly Python webdev) doing anything possible to avoid dealing with modern frontend and the toolchains that come with it. I’m not talking about frameworks, I’m talking about vanilla es6+ and occasionally leveraging npm the way they do Python package dependencies. I don’t blame folks for this but solid devops exists now. A lot of the pains around including modern js in a template driven web project have been worked out. The benefits including the cross browser compatibility, tree shaking and module importing and are there for the taking. Form manipulation, Ajax behaviors—-using JS to liven up your app can be learned and implemented.

Doxin 5y ago
Full stack dev here. I know plenty of frontend JS. I've written a chat application for my job that's currently in use by ~thousands of people among other things. This preface just to note that I'm not bad at JS or scared by it. I hate having to set up a "modern" js toolchain when starting a new project. No matter what tools you choose it's always a huge hassle, and it never manages to integrate seamlessly with the backend. What I like about HTMx and alpine.js is that first of all the set up is trivial. I just stick the js files in my static folder and stick a script tag in the header. Secondly they leverage exactly what the backend is good at: producing HTML. Getting the backend and frontend talking is trivial instead of a huge REST-y kludge. With modern JS I need to write database models, REST views, REST serializers, components, routing logic, etc. with HTMx and alpine I still need to write database models, views and templates but I get to fully skip the whole translation to and from REST (or whichever other API model you prefer). And in the end it's no less performant. So yeah for hobby projects I definitely avoid modern JS, but it's not for no reason. The developer experience is just awful IMO.