Hacker News new | ask | show | jobs
by ianpurton 552 days ago
Do some people have examples of interactivity they were able to replace with Htmx?

For me, I've been able to get turbo style links with the boost to get nice page transitions. I can also see how I could use the class-tools extension to enable buttons to open dialogs etc.

I'm curious to see when people say they needed an SPA for interactivity, what interactive features Htmx can already do and when do we need to break out some JS.

An example that I think needs JS is a copy paste button.

6 comments

One thing I use HTMX for is to quickly hack interactivity into a more traditional site.

One example is incremental filtering: I added an input field, and made it (a few ms after the last value change) load the same page the user is already on with a query parameter that filters the items in the response. Then I just replace the list of items with the contents from the response, ignoring the rest of the page.

It's a bit wasteful perhaps, but all this took just a few lines of HTML.

I tried HTMX but found it too restricting. It's great if you just want to load a portion of the page. Maybe if you have an up-vote, just send the request and replace the icon with a gold icon.

But I want things like an on-site calculator. I load in products and prices, users can adjust sliders to change the quantity and relevant number is calculated. I don't want to use HTMX for this to call the server each time, I want instant reactivity and state in the frontend maintained so when the user has tweaked as necessary they can just check out.

HTMX does not fit this use case so I use React to build widgets (or if even more complex SPA then Angular). If I'm using a JS framework anyway, then I don't need HTMX. It's just something else to clutter the project and remember to use.

HTMX has its place but with the user expectation for reactivity in the browser I personally find it too limiting.

Because HTMX is declarative and the declaration is in HTML, people have weirdly extended the "no need for js+json+rendering for ajax" to "don't use js".

This is making your life needlessly difficult.

HTMX is just a fancy ajax layer with a little event handling sprinkled on top. You can and should script to your heart content even if you use it, when you need so.

I use js in all most of my HTMX powered pages. Sometimes just a few lines. Sometimes a whole lot. Sometimes vanilla, sometimes alpine. I even have one where I load react for one single page because I want a community widget while the rest of the site is pure HTMX.

You can do whatever you want.

Of course you can combine the two but why use three tools (SSR + HTMX + JS) when I can just use two (SSR + JS)?

My point is that if you are going to use a JS framework then it will do the same as HTMX and I don't have to remember where to draw boundaries of responsibility.

htmx generalized hypermedia controls, so it makes HTML more powerful as a hypermedia:

https://dl.acm.org/doi/pdf/10.1145/3648188.3675127

that means you may be able to express more of your UI needs in HTML, using the traditional REST-ful architecture of the web (HATEOAS, in particular) and reserving JavaScript for the areas where that additional complexity adds the most value.

Depending on your application, this may lead to significant reduction in application complexity:

https://htmx.org/essays/a-real-world-react-to-htmx-port/

This kind of use case is where you’d use Alpine instead of HTMX (if you’re going for the no-build approach). It has everything you’d need for this, client-side store, etc. Alpine is basically light weight, no-build Vue.

HTMX is really only about swapping out the elements on the page and pushing updates to the server, which in this case might just be lazy loading the calculator component that contains Alpine attributes and Tailwind elements, and HTMX only if there are elements to swap or you need to save state to the server.

I haven't tried Alpine but I will investigate, thank you for the recommendation.
> when the user has tweaked as necessary they can just check out.

And what happens after the user spent all that time adjusting their order, submits it, and then is told at the very end that some items are out of stock? Do you think they're going to be happy about that?

What if their browser crashes and the order they had built up carefully is lost? Will they bother to try again?

Will you do price calculations properly with a proper decimal library or allow the user to see what IEEE754 floats think '0.1 + 0.2' should be?

Lot of questions come up with the client-only approach.

Appreciate the concerns but they're non issues.

Stock doesn't matter for my case.

The browser has storage options to handle close and reopens.

Prices in each currency are all in ints (i.e. cents) to avoid float issues.

There are problems to address on either end that you have to be aware of.

Good to know that it's not an issue in your case but just a reminder that your specific case is, by definition, not generalizable. These are problems that exist in general and have to be solved or prevented in some way. For example, you found some solutions that work for you but they won't for everyone.
I recently tried out htmx for rendering a web clone of the terminal UI for https://github.com/bjackman/limmat

It's a simple usecase but nonetheless I was blown away by how trivial HTMX made it! Very cool.

Interesting, I'm working on a similar project myself. Is your web clone open source?
The whole web part is in here: https://github.com/bjackman/limmat/blob/master/src/http.rs

Like 100 lines of code total to get it rendering in a browser with live updates over a web socket.

> An example that I think needs JS is a copy paste button.

And it’s fine? htmx allows you to write JavaScript. It’s probably one line, I don’t think everything you can come up with needs to be part of htmx.

It’s not all or nothing.

> An example that I think needs JS is a copy paste button.

Evidently you can use Hyperscript for this. Its website <https://hyperscript.org/> demonstrates it with a similar "copy" button.

I wrote plain HTML, JS, and CSS and it worked great in all browsers and all devices and passed all kinds of audits necessary in the real world.

Don't bother with libraries like this.

Go off King!