HTMX sets up an underlying network traffic pattern:
1. The user interacts with the page.
2. The page sends a request to the server.
3. The server returns one response to the client, containing HTML, which the client inserts into the page.
4. (Optional) If the response includes references to other resources, like images or fonts, the client makes more requests for these.
The consequence of the 'one request, one response' thing is that the whole thing is fast. All the HTML arrives in one go. None of this request-one-thing-then-run-some-JS-on-the-client-to-decide-whether-to-request-another-thing nonsense that you can watch happening in real time that happens in an alleged productivity tool I have to use at my day job.
Multicomp · 2m ago
/sarcasm/
Which is so much worse than the current paradigm where we have a client side SPA deciding to do all sorts of state syncing and react hooks and tracking pixels and auto pop ups all doing their own thing all over the place!
/end sarcasm/
I think for a side project, not immediately expecting your front end's first version to not horizontally scale to the moon is ok.
cyanydeez · 7m ago
so as long as you dont expect to scale, it works? Is the connection atleast long lived?
sgt · 4m ago
Htmx can scale. It's very basic and Htmx isn't the only technology to use that approach.
tekkk · 37m ago
I got a wave of shudder reading the acronym "HAM stack". Yugh. MEAN, MERN, RERN–once hyped up hot air which now sounds so dated and hackneyed. It's cool to be excited about tech but if your main selling point is building "faster and cheaper", I don't know if picking up a minimalistic framework you know nothing about is faster than just re-using your trusty boilerplate.
Be it React or Svelte or whatever. With serverless backend if you want to keep costs down. Although a server from Hetzner isn't that expensive and you can host multiple APIs there.
rapnie · 26m ago
I recently found Datastar [0], another hypermedia project. It was originally inspired by htmx, but they are fully on their own (hypermedia) course. According to the devs, who had a bunch of discussions with maintainers of htmx, the htmx project considers itself finished and no new features forthcoming. It is laudible, a project considering itself complete.
Datastar considers its library v1.0 release [1] to be complete, offering a core hypermedia API, while all else consists of optional plugins. The devs have a hot take wrt htmx in their release announcement:
> While it’s going to be a very hot take, I think there is zero reason to use htmx going forward. We are smaller, faster and more future proof. In my opinion htmx is now a deprecated approach but Datastar would not exist but for the work of Carson and the surrounding team.
When you think of adopting htmx, it may be worth making a comparison to Datastar as well.
At what point are we going to say browsers with JS is outdated and painful? Every few months there’s some new framework. I think it stems from the fact that we refuse to change the browser. HTML was nice but all these solutions to make it modern are…ugly. And don’t get me started on JS. I just want an elegant solution that’s intuitive and built for modern applications.
It's by the Flutter team lead talking about how with WASM we can redo the web stack by eschewing HTML, CSS, and JS entirely.
bnchrch · 34m ago
I think your suffering from the same thing that makes 2014 feel like 5 years ago when its over a decade ago.
The framework landscape has remained relatively entrenched in React since 2016. Sure theres a few new ones time to time but nothings ever come close to unseating it in the same way it took over from Angular.
(Yes you could argue Nextjs but thats just react with a backend bolted to it)
ChadNauseam · 31m ago
Many web developers make applications that are expected to work on every platform, every screen size, load instantly for new users, sync user state between every device instantly, and work offline (in some cases). All this takes place in an execution environment that perfectly sandboxes it, allowing users to download and run any application without any fear of viruses. Yes, the stack is complicated, but it's a complicated problem. The fact that people are making libraries to make web development simpler... well, no platform other than the web has even attempted to achieve everything I've listed, so we don't really have a point of comparison.
chistev · 6h ago
If it is too much of a pain with vanilla js, just use Svelte
Finnucane · 7h ago
“ This feels better to the user because changes feel faster”
This is debatable. Plenty of js heavy websites feel slow and clunky.
flemhans · 1h ago
Agreed, I'm always relieved to visit sites made the "old" way because they are fast.
ranger_danger · 1h ago
I can't believe they still don't have a way to parse JSON responses automatically.
If you combine e.g. hx-post with hx-target, then it will put the text from the response into the target selector... but there is no "hx-source" to select what part of the response to use.
I'd really love to be able to set e.g. hx-source="somejsonfield" instead of having to manually handle the response with a custom function that parses/error checks the json and then sets the selector's text to the value of a json key. It could really save a lot of boilerplate code IMO.
philipswood · 1h ago
The philosophy of HTMX is not to send JSON, but HTML fragments.
majorchord · 1h ago
They didn't mention sending JSON though... and you can absolutely return HTML fragments in a JSON response.
purerandomness · 58m ago
Then what's the point of using HTMX?
If you're not sending just exactly the necessary HTML to replace the target's HTML; if you need to parse JSON, then even jQuery would be better suited.
The whole idea of HTMX is to get rid of the extra steps.
ncruces · 1h ago
But why?
MountainMan1312 · 6h ago
I'm toying around with HTMX for my website. It's going to be sort of a wiki but a little different; the public exports from my internal knowledgebase with some extra crap mixed in.
I have lots of notes of varying types and formats. Org-mode files are all pretty standard, but there's like 3 different Markdowns and an untold number of randomly-formatted .TXT files. I want to generate their webpages on-the-fly and not have to worry about exporting it.
One of the "crap mixed in" things I want is to integrate parts of a gitweb-like interface into the notes. I reference repos and commits regularly in my notes. Would be neat to mouse-over them and get a little popup with basic info about it.
I also like that the author refers to themselves as a Technomancer. Personally I'm an metamagical artificer. I love meeting fellow adventurers.
hungryhobbit · 1h ago
HTMX seems like a solution in search of a problem.
nine_k · 40m ago
HTMX is a solution of a problem like the following: how to add small bits of server-based interactivity to an otherwise static HTML page?
One way would be to go with React, Nest.js, setting up SSR and hydration of just the right fragments, etc. Another would be to take your existing static HTML page, and add very few bits in a specific place.
An easy example: a "like" button + counter of "likes" under a blog post.
If you need a complex SPA UI, you need a different tool.
1. The user interacts with the page.
2. The page sends a request to the server.
3. The server returns one response to the client, containing HTML, which the client inserts into the page.
4. (Optional) If the response includes references to other resources, like images or fonts, the client makes more requests for these.
The consequence of the 'one request, one response' thing is that the whole thing is fast. All the HTML arrives in one go. None of this request-one-thing-then-run-some-JS-on-the-client-to-decide-whether-to-request-another-thing nonsense that you can watch happening in real time that happens in an alleged productivity tool I have to use at my day job.
Which is so much worse than the current paradigm where we have a client side SPA deciding to do all sorts of state syncing and react hooks and tracking pixels and auto pop ups all doing their own thing all over the place!
/end sarcasm/
I think for a side project, not immediately expecting your front end's first version to not horizontally scale to the moon is ok.
Be it React or Svelte or whatever. With serverless backend if you want to keep costs down. Although a server from Hetzner isn't that expensive and you can host multiple APIs there.
Datastar considers its library v1.0 release [1] to be complete, offering a core hypermedia API, while all else consists of optional plugins. The devs have a hot take wrt htmx in their release announcement:
> While it’s going to be a very hot take, I think there is zero reason to use htmx going forward. We are smaller, faster and more future proof. In my opinion htmx is now a deprecated approach but Datastar would not exist but for the work of Carson and the surrounding team.
When you think of adopting htmx, it may be worth making a comparison to Datastar as well.
[0] https://data-star.dev/
[1] https://data-star.dev/essays/v1_and_beyond
It's by the Flutter team lead talking about how with WASM we can redo the web stack by eschewing HTML, CSS, and JS entirely.
The framework landscape has remained relatively entrenched in React since 2016. Sure theres a few new ones time to time but nothings ever come close to unseating it in the same way it took over from Angular.
(Yes you could argue Nextjs but thats just react with a backend bolted to it)
This is debatable. Plenty of js heavy websites feel slow and clunky.
If you combine e.g. hx-post with hx-target, then it will put the text from the response into the target selector... but there is no "hx-source" to select what part of the response to use.
I'd really love to be able to set e.g. hx-source="somejsonfield" instead of having to manually handle the response with a custom function that parses/error checks the json and then sets the selector's text to the value of a json key. It could really save a lot of boilerplate code IMO.
If you're not sending just exactly the necessary HTML to replace the target's HTML; if you need to parse JSON, then even jQuery would be better suited.
The whole idea of HTMX is to get rid of the extra steps.
I have lots of notes of varying types and formats. Org-mode files are all pretty standard, but there's like 3 different Markdowns and an untold number of randomly-formatted .TXT files. I want to generate their webpages on-the-fly and not have to worry about exporting it.
One of the "crap mixed in" things I want is to integrate parts of a gitweb-like interface into the notes. I reference repos and commits regularly in my notes. Would be neat to mouse-over them and get a little popup with basic info about it.
I also like that the author refers to themselves as a Technomancer. Personally I'm an metamagical artificer. I love meeting fellow adventurers.
One way would be to go with React, Nest.js, setting up SSR and hydration of just the right fragments, etc. Another would be to take your existing static HTML page, and add very few bits in a specific place.
An easy example: a "like" button + counter of "likes" under a blog post.
If you need a complex SPA UI, you need a different tool.
https://swag.htmx.org/en-usd/collections/htmx-sucks