Comment by bityard | Hacker News Reader

Comment by bityard | Hacker News Reader

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.

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.

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.

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.

HTMX + Alpine JS seems to be prevalent.

It's hilarious to me that HTMX is JS code and Alpine.js is HTML.

its js too? https://alpinejs.dev/essentials/installation#as-a-module

I was going by Github language stats indicating 90% HTML / 10% JS https://github.com/alpinejs/alpine

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.

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.

HTMX has quite a few before/after events that you can respond to:

https://htmx.org/reference/#events

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.

Reply on news.ycombinator.com