Item — HN Reader

I’m very grateful for how htmx by focussing on a very specific part of “interactive JavaScript on the page” was able to shift a whole bunch of similar JavaScript actions into an elegant abstraction that rested so neatly on all the existing work that had/has gone into developing html. And even for having the clarity to name it as such.

In a way it’s a bit of a lesson in managing complexity, rather than seek to be “the next JavaScript framework to replace all the others with its theory of the universe”, it instead carved off a smaller slice and said these Thich are related, we’re just for dealing with these thing, nothing more.

In one swoop a whole raft of manual developer programming workload was packed up with a new easier to understand abstraction.

Kudos to the team, I’m grateful for the considered way you’ve developed this tool for the rest of us.

1 comments

how do you feel about its adoption in things like https://fastht.ml/ ? i was open to the idea at first esp with jeremy howard's endorsement, but once you start updating multiple things on a page at once i felt like i was fighting htmx rather than it helping me. components are a really neat paradigm and just bc react is currently in a complexity upswing doesnt mean we want to throw the baby out with bathwater

You can build your own python component implementation on top of htmx, like in the example you show. That is not a failing of htmx IMO.

thats not what the js world traditionallyunderstands as a component - eg - it doesnt take an argument that, when the argument value changes, the component rerenders. you still have to wire all that up with htmx (again, as far as i undersatnd it, having spent a week with htmx)

You can do that with HTMX through events and hx-trigger but it just sounds like HTMX isn't the right tool for what you're trying to do. I've seen a lot of instances of people trying to use HTMX to replace react/vue/etc. and not understanding that they're trying to solve for very different things.

HTMX highly encourages client side scripting for dynamic updates if that's what your UI needs. It's very pro-JavaScript even though a lot of people get confused and try to use it to fully replace JavaScript

I think web components would be an excellent pairing with htmx. You get some kind of component abstraction (admittedly janky in some ways, though libraries like lit or atomico make this much better). But crucially you get automatic upgrade/initialize behaviour whenever the browser encounters a custom element. So the backend can just send down the custom elements as plain html, you don't need to wire anything up, the browser will bring them to life.

The problem is web components (which are great) are not so good for seo. You would be losing the auto SSR benefits of using your own component abstraction in any backend language.

That to me sounds external/additional to the idea of a component.

You can do the component side on your backend language of choice, and output html like htmx likes it, and it works (have done it in Python, for example).

It is extra work, but it works with a bit of programming.