htmx
I have immensely enjoyed and benefited from using htmx for the past 18 months on projects with Clojure as the backend language. I had done years of full-stack Angular then React on the front-end and Java Rest endpoints on the back-end with teams of all sizes.
htmx has been a revelation and has really opened my eyes to the nuances of hypermedia development modalities that I was ignorant of. For me, it has become very clear that htmx and hypermedia development is far more simple, productive, beneficial, and FUN for 90% of web dev use cases. I feel huge disappointment how unnecessarily web development evolved into bad client server rpc json protocol for basically everything web.
Kudos to the htxm creator and his vision of what should have been. My experience absolutely corroborates his thinking on these things.
Heh, the "Memes" section of their Essays page is brilliant: https://htmx.org/essays/#memes
Hmmmm... no.
This:
Should be just this:<button hx-post="/clicked" hx-swap="outerHTML"> Click Me </button>
This way, no magic would be needed, a lot of indirection and complexity would be avoided and everybody who knows HTML and JS could immediately read and understand it:<button onclick="htmx.post('/clicked', 'outerHTML')"> Click Me </button>- When does something happen here? When the button is clicked. - What does happen? htmx.post() is called.I use htmx heavily on https://golfcourse.wiki
It’s nice and easy to work with, and lets me keep almost everything in python (flask).
It’s a bit more bandwidth, but it’s a hobby/bootstrapped project right now, and since it’s an api, if I ever make any money, it’ll be easy to rewrite and heavy lifting.
I like it because I’ll write 3x the code in the same amount of time if it’s python. I just don’t like js much even though I know it’s fine.
"Load HTML from a URL and replace part of the page with it" is a powerful technique for progressive enhancement, even if you don't want to use a framework like this. A button can send users without JavaScript to the URL directly, while users with JavaScript can have that part of the page replaced inline.
HTMX is just HTML.
HTMX substitutes a DOM element with the HTML response you get from an on-click HTTP request instead of redirecting to a new page.
Claims of HTMX being yet another complexity or yet another JavaScript framework fail to acknowledge this.
This is VERY cool. I’m very excited to see a project like this. Is it me or there has been a lack of wow-factor projects lately like when jquery was introduced. Or templating engines like handlebars. Or when angular and react took over. Browsing the htmx site felt like learning about those aforementioned projects for the first time.
I love htmx and have used it to build internal tools quite successfully. It allows me to work in my preferred language on the backend, write some basic ass html and spinkle in a few attributes and get some frontend reactivity that I otherwise wouldn’t have because I hate Javascript.
My problem with this approach is the same one raised by Dijkstra against the goto statement. These update actions are too unrestricted and don't offer any way to analyze the program's progress systematically, based on the program source code.
I continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well have setup a JS bundler in the first place, and yet the debugging, testing and deploying challenges will continue to push you into less-trodden territory.
I believe there might be a sweet spot for small projects unlikely to grow in complexity, maintained by a Python dev who is allergic to JS. But I don't see why you would want to invite yet another abstraction into the web stack, when it's built on top of the very language you're trying to avoid, and which you'll inevitably encounter in all its automagically obfuscated glory as soon as you run into a moderately complex problem.
I'd still pick Unpoly over it. Seems far more high level, feature rich and easier to use although less popular. And if I wanted a popular approach I'd pick Hotwire which can be used with any backend framework anyways.
I really want to use htmx on the next project but I am not sure how to make it handle poor network connections yet. The app I'm building will be used in areas with poor mobile connections - I want to submit a form, add it to a list and say it's pending saving, while the user can add more. Have to use hyperscript probably?
Can trivially do it in vanillajs so I'm sure it's possible?
Ah yes…the daily htmx post
Does this cause problems for web crawlers indexing sites, since these are not typical js event listeners etc? Even though they must use them in the background, there is an abstraction the crawler must be able to navigate. I had an entire site de-indexed for getting too fancy once, so I worry about this type of thing perpetually now.
For those with flexibility or a new project, also consider Phoenix LiveView. It’s been a joy to work with so far.
HTMX + Java is almost as good as react!
I think people mistake what htmx is - they think it is a way to not write react/js in a node environment.
Where HTMX really shines is being able to bring the experience of writing React-like code without a nodejs environment in Java for e.g. (or Golang, Rust, etc)
How does htmx compare with alpinejs (https://alpinejs.dev/)?
On the one hand I see the appeal of staying inside, say, Django the whole time and getting 3x done.
On the other hand I am so pampered by front end component based templating especially with Tailwind.
It would be cool if I could just import my Svelte components from Django.
how many times has this been posted here?
Can HTMX be used with static site generators, such as Hugo, to create interactive documentation websites?
This is the first time I've been excited to learn about a new web technology in a while. I'm going to have to play around with this to see how I want to use it. I wonder what other little things like this could be used to simplify webdev?
The crucial flaw with htmx is that it’s an enhancement of html itself; if a fancy and interesting new UI pattern is invented somewhere, the htmx devs or contributors will have to add support for it into htmx itself!
And imagine if htmx became absorbed into the real html standard. It would take much longer for the standards body (and then browser makers) to respond and implement.
So the crucial flaw is that it will always be reacting instead of innovating. And more generally, this is likely why the “thick client” approach is more popular on the web these days. Nobody wanted to wait around for standards bodies and browser makers.
I'm not a fan of adding functionality to hypertext attributes. I want an expected set of attributes to a component, not a new set of attributes that extend existing components. A lot of functionality can get obfuscated.
Long arguments here about whether HTMX or React or something else can qualify as idiomatic HTML.
But the truth is, HTML itself does so very little that it’s barely useful as a starting point for building applications.
Arguing about idiomatic HTML in this context is like arguing about how to write a scientific paper in idiomatic toddler language. One faction thinks you should stick to monosyllabic words. Another believes drawings of colorful balloons are key. Both are held back by the fundamental assumption.
The filler text on some of the examples (e.g. https://htmx.org/examples/tabs-hyperscript/) seems to be generated by Hipster Ipsum https://hipsum.co/. Cute.
I kinda like the aesthetic. It feels a bit like what HTML might have looked like if XHR had been baked in.
I personally don't see the utility in this too much, but then I'm old fashioned and go out of my way to use as little JS as possible, doing everything via CSS as much as I can.
Even though JS is ubiquitous and small, well written JS is harmless, I still try to avoid it like the plague. Maybe just to somewhat fight back against all the excessive JS that plagues every site.
A lot of this what htmx does is a one-liner in Jquery. I know: the unpopular old thing :)
Learning to use any new tool comes at a time cost, and if I learn this and then a newer, more convenient tool emerges that can replace it, I get stuck in the question.
Are people driving the tools?
Or are the tools binding people?
This vaguely reminds me of Adobe's ColdFusion except in the browser for better or worse.
can htmx be used offline? i.e. am I screwed if I load an htmx page, close a laptop and get on a plane?
stop trying to make htmx happen, it's not going to happen
Seems like a horrible idea that totally breaks separation of concerns, so I’m sure it will be a huge success you’ll see everywhere very soon.